10장 : 클래스

*<클린 코드>를 참고하여 작성한 글입니다.

클래스

• 클래스 체계 : 프로그램은 신문 기사처럼 읽힌다. 추상화 단계가 순차적으로 내려간다.
• 캡슐화 : 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야한다는 법칙도 없다. 때로는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 하지만 그 전에 비공개 상태를 유지할 온갖 바업을 강구한다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
• 클래스는 작아야 한다
  • 책임이 적어야 한다.
  • 클래스 이름은 해당 클래스 책임을 기술해야 한다. 간결한 이름이 떠오르지 않는다면 클래스 크기가 너무 큰 것이다.
  • 딘일책임원칙 : 크래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 법칙. 책임, 즉 변경할 이유를 파악하려 애쓰다보면 코드를 추상화하기도 시ㅜ워진다. 더 좋은 추상화가 더 쉽게 떠오른다. SRP는 객체지향설계에 더욱 중요하며, 이해하고 지키기 수월한 개념이다.
  • 응집도 : 클래스는 인스턴스 변수 수가 작아야 한다. 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
    • '함수는 작게, 매개변수 목록을 짧게'라는 전략을 따르다보면 때때로 몇몇 메서드만이 사용하는 인스천스 변수가 아주 많아진다. 이는 새로운 클래스로 쪼개야 한다는 신호다. 응집도가 높아지도록 변수, 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.
• 변경하기 쉬운 클래스
  • 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
  • 변경으로부터 격리 : 상세한 구현에 의존하는 코드는 테스트가 어렵다. 테스트가 가능할정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합도가 낮다는 것은 각 시스템 요소가 다른 요소로부터, 그리고 변경으로부터 잘 격리되어있다는 의미다. 시스템 요소가 서로 잘 격리되어 있으면 각 요소를 이해하기도 더 쉬워진다. 이렇게 결합도를 최소로 줄이면 자연스럽게 DIP를 따르는 클래스가 나온다. 즉, 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.