클래스 체계
변수 목록(static public constant -> static private variable -> private variable) -> public method -> private method(Next to caller)
캡슐화
변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만, 반드시 숨겨야 하는건 아니다. (protected로 테스트 코드에 접근 허용)
하지만 그 전에 비공개 상태를 유지할 온갖 방법을 강구하자.
클래스는 작아야 한다!
함수가 물리적인 행 수로 크기를 측정한다면,
클래스는 맡은 책임을 센다.
클래스 이름은 해당 클래스 책임을 기술해야 하는데,
- 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 커서 그렇다.
- 클래스 이름이 모호하다면 클래스 책임이 너무 많아서다. (Processor, Manager, Super 등...)
단일 책임 원칙
Single Responsibility Principle, SRP 는 클래스나 모듈을 변경할 이유(책임)가 단 하나뿐이어야 한다는 원칙이다.
걱정: 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워지지 않을까?
반박: 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 직접 영향이 미치는 컴포넌트만 이해해도 충분하다. 큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.
응집도
Cohesion 가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미다.
응집도가 높아지도록 변수와 메섣르르 적절히 분리해 새로운 클래스로 쪼개준다.
응집도를 유지하면 작은 클래스 여럿이 나온다
클래스가 응집력을 잃는다면 쪼개라!
변경하기 쉬운 클래스
어떤 변경이든 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다. => SRP 를 지키자. (파생 클래스를 만들어 책임 분리, OCP도 지킬 수 있다.)
클래스 일부에서만 사용되는 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사한다. => 유틸리티 클래스를 만들자.
변경으로부터 격리
상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.
DIP Dependency Inversion Principle 는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.
