[클린 코드] 10장 클래스

클래스 체계

클래스를 정의하는 표준 자바 관례에 따르면, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 뉴스 기사처럼 읽힌다. 

• 일반적인 순서
  • 변수 목록: static public 상수 -> static private 변수 -> private instance 변수 -> (드물게) public 변수
  • 함수 목록: public 함수 -> private 함수(자신을 호출하는 public 함수 직후에)

캡슐화

변수와 유틸리티 함수는 공개하지 않는 편이 낫다. 테스트 코드가 함수를 호출해하거나 변수를 사용해야한다면 protected로 선언하거나 패키지 전체에 공개할 수는 있겠다. 그러나 그것은 최후의 수단이 되어야한다.

클래스는 작아야 한다!

함수에서 물리적인 행 수로 크기를 작게 유지했다면, 클래스에서는 클래스가 담당한 책임의 수를 센다.

클래스의 간결한 이름이 떠오르지 않으면 클래스의 크기가 너무 커서이다. 클래스의 이름이 모호하다면 클래스의 책임이 너무 많아서이다. 클래스 이름에 Processor, Manager 와 같은 모호한 단어가 있다면 클래스에다 여러 책임을 떠안겼다는 증거다.

단일 책임 원칙

단일 책임 원칙(Single Responsibility Principle, SRP)는 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다. 

이상하게도 우리는 수많은 책임을 떠안은 클래스를 꾸준하게 접한다. 왜일까?

소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. '깨끗하고 체계적인 소프트웨어'보다 '돌아가는 소프트웨어'에 초점을 맞춘다. 이렇게 관심사를 분리하는 작업은 프로그램만이 아니라 개발자의 프로그래밍 활동에서도 마찬가지로 중요하다. 또, 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다.

하지만 규모가 어느 수준에 이르는 시스템은 논리가 많고 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. "도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 놓고 싶은가?" 큼직한 다목적 클래스 몇 개로 이루어진 시스템은 변경을 가할 때 당장 알 필요가 없는 사실까지 들이밀어 개발자를 방해한다.

 

응집도 Cohesion

응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다.

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

'함수를 작게, 매개변수 목록을 짧게'라는 전략을 따르다 보면 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아진다. 이는 새로운 클래스로 쪼개야 한다는 신호일 수 있다. 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개준다.

 

 

변경하기 쉬운 클래스

OCP(Open-Closed Principle)란 클래스는 확장에 개방적이고, 수정에 폐쇄적이어야 한다는 원칙이다. 

변경으로부터 격리

테스트가 가능할 정도로 시스템의 결합도를 낮추면 유연성과 재사용성도 높아진다. 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되었다는 의미다. 시스템 요소가 잘 격리 되어있으면 각 요소를 이해하기도 더 쉬워진다.

이렇게 결합도를 낮추면 자연스럽게 또 다른 클래스 설계 원칙인 DIP(Dependency Inversion Principle)을 따르는 클래스가 나온다. 본질적으로 DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

 

 

출처: 도서 클린코드 애자일 소프트웨어 장인 정신, 로버트 C.마틴 지음 | 박재호, 이해영