November 24, 2021 1 min to read

10. 클래스

코드의 표현력과 그 코드로 이루어진 함수에만 신경 쓴다고 깨끗한 코드를 얻는 것은 아니다. 더 높은 차원의 단계까지 신경 써야 한다.

클래스 체계

때때로 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 하지만 그 전에는 최대한 비공개 상태를 유지해야 한다.

캡슐화를 풀어주는 결정은 언제나 최후의 보루다.

클래스는 작아야 한다. 클래스 안에 메서드가 너무 많아지면 그에 비례하여 책임이 많아진 다는 것이고 이는 단일 책임 원칙에 위배될 수 있다.

클래스는 책임, 즉 변경할 이유가 단 하나여야 한다는 원칙을 말한다.

책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.

큰 클래스 몇 개보다는 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.

클래스는 인스턴스 변수 수가 적어야 한다. 그리고 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다.

함수를 작게, 매개변수 목록을 짧게라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 클래스를 쪼개야 한다는 신호다.

클래스가 응집력을 잃는다면 쪼개라!

클래스가 쪼개질수록 구조는 명확해진다.

구체적인 클래스와 추상 클래스를 활용하여 OCP를 지킬 수 있다.

결합도를 낮출수록 시스템 요소가 서로 잘 격리되어 있으므로 각 요소에 대한 이해도 쉽다. 이렇게 결합도를 최소로 줄이면 DIP를 따르는 클래스가 나온다.