Clean Code 10장 - 클래스

• 클래스 체계
• 클래스는 작아야 한다
• 변경하기 쉬운 클래스

형식을 맞추는 목적

• 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다.
• 때로는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다.
• 하지만 허용하기 전에 비공개 상태를 유지할 온갖 방법을 강구한다.
• 언제나 캡슐화를 풀어주는 결정은 최후의 수단이다.

클래스는 작아야 한다!

• 클래스는 작아야 한다.
• 클래스의 크기를 세는 척도는 클래스가 맡은 책임 이다.
• 메서드가 줄어든다고 책임이 줄어드는 것이 아니다.
• 클래스 이름을 지을만한 간결한 이름이 떠오르지 않는다면 클래스가 너무 커서 그렇다. (여러 책임을 떠안고 있다.)

단일 책임 원칙

• 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야 한다.
• 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.
• 게다가 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다.
• 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다.

하지만 작은 클래스가 많은 시스템이든 큰 클래스가 몇 개뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다.
 어느 시스템이든 익힐 내용은 그 양이 비슷하다. 그러므로 고민할 질문은 다음과 같다.
  “도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가?
   아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?”
규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다.
 이런 복잡성을 다루려면 체계적인 정리가 필수다.
  그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다.
   그래야 변경을 가할 때 직접 영향이 미치는 컴포넌트만 이해해도 충분하다.

• 큼직한 다목적 클래스 몇 개로 이루어진 시스템은 변경을 가할 때 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.

응집도

• 클래스는 인스턴스 변수 수가 작아야 한다.
• 클래스 안에서 메서드마다 많은 인스턴스 변수를 사용하고 있다면 응집도가 높다.
• 무조건 응집도가 높은게 좋은 것이 아니라 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶여있기에 좋은 것이다.

응집도를 유지하면 작은 클래스 여럿이 나온다

• 클래스가 응집력을 잃는다면 쪼개자
• 큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.
• 클래스를 분리하다보면 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.

변경하기 쉬운 클래스

• 깨끗한 시스템은 클래스를 체계적으로 정리해 지속적인 변경에도 발생할 수 있는 위험을 낮춘다.

변경으로부터 격리

• 요구사항은 변하기 마련이고 코드 역시 변하기 마련이다.
• 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
• 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
• 상세한 구현애 의존하는 코드는 테스트가 어렵다.
• 테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
• 자연스럽게 DIP를 따르는 클래스가 나온다.