10. 클래스

아무리 코드의 표현력과 함수에 신경 쓸지라도 더 높은 차원에 단계인 클래스에 신경쓰지 않으면 깨끗한 코드를 얻기 힘들다.

클래스 체계

• 클래스를 정의할 때는 표준 자바 관례에 따른다. 추상화의 단게가 내려갈수록 낮아진다.
  1. static public 변수
  2. static private 변수
  3. private 인스턴스 변수 (public 인스턴스 변수는 거의 쓰지 않는다)
  4. public 함수
  5. private 함수

캡슐화

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

클래스는 작아야한다

• 클래스 원칙. 클래스는 무조건 작게. 3장. 함수편과 동일한 맥락이다.
• 함수의 크기는 행 수로 측정했지만, 클래스는 클래스가 맡은 책임을 센다. 매서드가 적더라도 책임이 너무 많으면 의미 없다.
• 클래스 이름은 해당 클래스 책임을 알려줄 수 있어야 한다. 간결한 이름이 떠오르지 않는다면 클래스 책임이 너무 많은 것이다.
• 클래스 이름이 너무 모호하다면 책임이 너무 많을 가능성이 높다. ex) super, manager, processer가 들어가는 클래스 이름

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

• 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야한다는 원칙이다.
• 객체 지향 설계에서 엄청 중요한 개념. 이해하고 지키기 수월한 개념이지만 클래스 설계자가 가장 무시하는 규칙 중 하나다.
• 깨끗하고 체계적인 소프트웨어보다 돌아가는 소프트웨어에 초점을 맞추다보니 일어난다.
  올바른 태도이지만 만든 이후 깨끗하고 체계화된 코드로 바꾸는 작업을 하지 않고 다음 문제로 넘어가는 것이 문제다.
• 규모가 클수록 시스템은 논리가 많고 복잡해진다. 체계적인 정리가 필수!

응집도 (Cohesion)

• 클래스는 인스턴스 변수가 적어야 한다.
• 각 클래스 메서드는 클래스 인스턴스 변수를 하나 이상 사용해야 한다. 많이 사용할수록 응집도가 높다.
• 응집도를 유지하면 작은 클래스가 여럿 나온다. 큰 함수를 작은 함수로 쪼개다보면 클래스를 쪼갤 기회가 생긴다. 그럴수록 프로그램엔 점점 더 체계가 잡히고 구조가 투명해진다.

클래스 쪼개기 팁 : 재구현하지 않는다. 테스트 슈트를 작성하고, 한 번에 하나씩 수 차례에 걸쳐 조금씩 코드를 변경한다. 변경할 때마다 테스트를 수행해 동일하게 동작하는지 확인한다.

변경하기 쉬운 클래스

• 시스템은 지속적으로 변경된다. 뭔가를 변경할 때마다 시스템이 의도대로 동작하지 않는 위험은 없어야한다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경이 가져오는 위험을 낮춘다.
• 각 클래스는 단순하고 순식간에 이해할 수 있게 작성되어야 한다. 함수 하나를 수정했다고 다른 함수가 망가질 위험이 있어선 안된다.
• 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 적어야 바람직하다. 이상적인 시스템은 기능을 추가할 때 시스템을 확장할 뿐 코드를 변경하지 않는다.

요구사항은 늘 변한다. 따라서 코드는 변한다.

변경으로부터 격리

• 객체지향에서 구체적인(Concrete) 클래스, 추상(Abstract) 클래스가 있다. 구체적인 클래스는 상세한 구현(코드)을 포함하며 추상 클래스는 개념만 포함한다. 상세한 구현에 의존한 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
• 너무 구체적인 클래스는 테스트하기도 힘들다. 테스트가 가능할 정도로 결합도를 낮추면 오히려 유연성과 재사용성도 높아진다. 결합도가 낮을수록 다른 요소의 변경에서 자유롭다. 각 요소를 이해하기도 쉽다.