북클럽 클린코드 10장. 클래스

클래스 체계

• 클래스를 정의하는 표준 자바 관례에 따르면
• 가장 먼서 변수 목록이 나온다.
• 정적 공개 상수가 있다면 맨 처음에 나온다.
• 다음으로 정적 비공개 변수가 나오며
• 이어서 비공개 인스턴스 변수가 나온다.
• 공개 변수가 필요한 경우는 거의 없다.
• 변수 목록 다음에는
• 공개 함수가 나온다.
• 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다.

클래스는 작아야 한다

• 클래스는 작아야 한다.
• 더 작아야 한다.
• 작게가 기본 규칙이다.
• 그러면 얼마나 작아야 하는가?
• 함수는 물리적인 행 수로 크기를 측정했다.
• 클래스는 다른 척도를 사용한다.
• 클래스가 맡은 책임을 센다.
  • 메서드 개수도 작아야 하지만
  • 메서드 개수만 작다고 책임도 작은건 아니다.
• 클래스 이름
  • 클래스의 책임을 기술한다.
  • 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다.
  • 클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다.
  • 클래스 이름에 Processor, Manager, Super 등과 같이 모호한 단어가 있다면 클래스에다 여러 책임을 떠안겼다는 증거다.
• 클래스 설명
  • 클래스 설명은 만약, 그리고, ~하며, 하지만 을 사용하지 않고 설명해야 한다.
  • 25단어 내외로 설명해야 한다.
• 단일 책임 원칙
  • 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다.
  • 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미
  • 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.

우려

• 혹자는 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다.
• 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다.
• 작은 클래스로 돼있든 큰 클래스로 돼있든 돌아가는 부품은 그 수가 비슷하다.
• 고민할 질문은 "도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?"

응집도(Cohesion)

• 클래스는 인스턴스 변수 수가 작아야 한다.
• 각 클래스 메서드는 클래스 이늣턴스 변수를 하나 이상 사용해야 한다.
• 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다.
• 모든 인스턴스 변수를 메서드마다 사용하는 클래스는 응집도가 가장 높다.
• 우리는 응집도가 높은 클래스를 선호한다.
• 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미기 때문이다.
• 함수를 작게, 매개변수 목록을 짧게 라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다.
• 이는 십중팔구 새로운 클래스로 쪼개야 한다는 신호다.
• 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

몇몇 함수가 몇몇 변수만 사용한다면 독자적인 클래스로 분리해도 되지 않는가?
당연하다. 클래스가 응집력을 잃는다면 쪼개라.
큰 함수를 작은 함수로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.

코드를 쪼개면 프로그램이 길어진다. 그게 정상이다.

변경하기 쉬운 클래스

• 코드에 손을 대면 고장날 위험이 생긴다.
• 경험에 의하면 ㅋ르래스 일부에서만 사용된느 비공개 메서드는 코드를 개선할 잠재적인 여지를 시사한다.
• 하지만 실제로 개선에 뛰어든느 계기는 시스템이 변해서라야 한다.
• Sql 클래스를 논리적으로 완성이라 여긴다면 책임을 분리하려 시도할 필요가 없다.
• 가까운 장래에 update 문이 필요하지 않다면 Sql 클래스를 내버려두는 편이 좋다.
• 하지만 클래스에 손대는 순간 설계를 개선하려는 고민과 시도가 필요하다.

새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.
이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.