[CleanCode]클래스 1

 

클래스 선언 순서

1. 변수 목록
   1. 정적 공개 상수
   2. 정적 비공개 변수
   3. 비공개 인스턴스 변수
   4. 그 외 변수 목록
2. 함수
   1. 공개 함수
   2. 비공개 함수는 자신을 호출하는 고 함수 직후에 넣는다

공개 변수가 필요한 경우는 거의 없다.
즉, 추상화 단계가 순차적으로 내려간다.

---

캡슐화
: 변수와 유틸리티 함수는 공개하지 않는 편이 낫다

2024.04.02 - [☕ 자바 JAVA/☕ 클래스와 함수 Class & Method] - [JAVA]접근 제어자/제한자 access modifier

현재 클래스만 되도록 private 제일 추천. 데이터 내보낼 땐 함수로.

때로는 같은 패키지 안까지만 호출 가능하도록 protectec나 default로 한다.

private을 쓰는 게 이상적이다.
하지만 같은 패키지 안에서 쓰이는 경우에는 protected나 default를 사용한다.

하지만 그 전에 비공개 상태를 유지할 방법을 강구한다.
캡슐화를 풀어주는 결정은 언제나 최후의 방법이다.

---

클래스는 작아야 한다
→ 책임이 적어야 한다

안 좋은 예 한 클래스에 기능을 몰아 넣으면 책임이 많아진다.

클래스 이름은 해당 클래스 책임을 기술해야 한다.

• 만약 간결한 이름이 떠오르지 않고 Processor, Manager, Super가 들어가야 한다면 클래스 크기가 큰 것이다.
• 클래스 설명을 if, and, or, but (만일, 그리고, 하며, 하지만)을 사용하지 않고서 25단어 내외로 적을 수 있어야 한다.

---

단일 책임 원칙
SRP
Single Responsibility Principle
: 클래스나 모듈을 변경할 이유가 하나여야 한다.

언제 이 클래스를 수정해야

1. 로그인 기능을 수정이 필요할 때
2. 게시글 기능을 수정할 때
3. 댓글을 수정할 때
4. ..

 클래스나 모듈을 수정해야하는 이유는 하나여야 한다.

 SRP는 개발자들이 가장 무시하는 규칙 중 하나다.
우리 대다수는 '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다.

 많은 개발자들이 단칠 책임 클래스가 많아지면 큰 그림을 이해하기 어려워지기 우려한다.
큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 왔다갔다 해야한다 걱정한다.
 하지만 클래스가 작든 크든 부품(method)수는 비슷하다.

 '많은 서류를 정리할 때 큰 서랍 몇 개에 나눠서 던져둘 것인가, 파일에 차곡차곡 나눠 담을 것인가'
당연히 작은 클래스 여럿으로 이뤄진 시스템이 바람직하다.