클래스 체계
- 변수 목록 -> 정적 공개 상수 -> 정적 비공개 변수 -> 비공개 인스턴스 변수 -> 공개 함수 -> 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다
- 추상화 단계가 순차적으로 내려간다.
클래스는 작아야 한다
- 클래스도 함수와 마찬가지로 '작게'가 기본 규칙이다.
- 함수는 물리적인 행 수로 크기를 측정했다면 클래스는 맡은 책임을 센다.
- 클래스 이름은 해당 클래스 책임을 기술해야 한다.
단일 책임 원칙 SRP(Single Responsibility Principle)
- 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙
- 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
- 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
응집도 Cohesion
- 클래스는 인스턴스 변수 수가 작아야 한다.
- 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다.
- 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다.
- 몇몇 메서드만이 사용하는 인스턴스 변수가 많아지면 새로운 클래스로 쪼개야 한다는 신호다
응집도를 유지하면 작은 클래스 여럿이 나온다
- 클래스가 응집력을 잃는다면 쪼개라
- 클래스를 쪼개다 보면 프래그램에 점점 더 체계가 잡히고 구조가 투명해진다.
변경하기 쉬운 클래스
- 대다수 시스템은 지속적인 변경이 가해진다.
- 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
- OCP(Open-Closed Principle): 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙
- 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
변경으로부터 격리
- 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다.
- 결합도를 최소로 줄이면 자연스럽게 DIP를 따르는 클래스가 나온다.
- DIP (Dependency Inversion Principle): 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙
yesjm's second brain