10. 클래스

클래스 체계

• 변수목록
  • static public
  • static private
  • 비공개 인스턴스 변수
• 함수
  • 공개
  • 비공개 (자신을 호출하는 공개 함수 직후에 배치)

캡슐화

• 변수와 유틸리티 함수는 가능한 공개하지 않는 것이 낫지만 반드시 숨겨야 한다는 법칙도 없다.
• 종종 변수와 유틸리티 코드를 protected로 선언(비공개로 함수를 만들어 TC를 짤 수 있다면 best)해 테스트 코드에 접근을 허용하기도 한다.

클래스는 작아야 한다

• 물리적 크기도 중요하지만 클래스가 갖는 ‘책임’의 수가 작아야 한다.
• 클래스 이름: 클래스의 책임을 기술 (Processor나 Manager가 붙은 이름은 클래스 하나가 여러 책임을 떠안은 것)

단일 책임 원칙 (SRP, Single Responsibility Principle)

• 클래스나 모듈을 변경할 이유가 ‘하나’여야 한다.
• 큰 클래스 몇 개보다 작은 클래스 여러개로 이루어진 시스템이 더 바람직하다.

응집도 (Cohesion)

• 클래스는 인스턴스 변수 수가 작아야 한다.
• 응집도가 높다: 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.
  • 응집도가 높아지도록 변수와 메서드를 적절히 분리해서 새로운 클래스 두세개로 쪼갠다.
• 응집도를 유지하면 작은 클래스 여럿이 나온다.

변경하기 쉬운 클래스

• 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춤.
• 새 기능을 추가하거나 수정할 때 건드릴 코드가 최소인 시스템이 바람직하다.
  • 시스템을 확장하고 기존 코드는 건드리지 않는 것이 좋음
• 변경으로부터 격리
  • 결합도가 낮다 = 각 시스템 요소가 다른 요소로부터, 변경으로부터 잘 격리되어 있다.

OCP (Open-Closed Principle)

• 확장에 개방적, 수정에 폐쇄적

DIP (Dependency Inversion Principle)

• 클래스가 상세한 구현이 아닌 추상화에 의존해야 한다.

---

클래스를 처음 짤 때는 괜찮았는데 이후에 스펙이 추가되거나 수정되면 점점 더 클래스의 크기가 커지곤 했었는데…. 때마다 리팩토링을 해줬어야 했군… 클래스를 적당한 책임의 크기로 유지하는 것이 중요하다는 것을 알게 된 챕터였다.