[Clean Code] TIL - 220209

10장. 클래스

 

관리하기 쉽도록 하나씩 집중하자.

 

1. 생각

클래스도 함수와 마찬가지로 작은 크기가 좋다.

하지만 크기의 척도가 함수와는 달리 맡은 '책임'을 기준으로 측정한다.

클래스가 맡은 책임과 변경의 이유가 하나씩이어야 한다.

 

프로그램을 돌아가게 만드는 것과 깨끗하게 정리하는 것을 별개의 활동이다.

그러므로 실행 가능하게 구현한 다음엔 정리해서 보기 좋게 만드는 작업을 거쳐야한다.

 

 

2. 기억하고 싶은 내용들

코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다.

 

- 클래스 체계

즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다.

 

캡슐화

때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다.

하지만 그 전에 비공개 상태를 유지할 온갖 방법을 강구한다. 캡슐화를 풀어주는 결정은 언제나 최후의 결정이다.

 

- 클래스는 작아야 한다!

단지 클래스를 설계할 때도, 함수와 마찬가지로, '작게'가 기본 규칙이라는 의미다.

함수는 물리적인 행 수로 크기를 측정했다. 클래스는 다른 척도를 사용한다. 클래스가 맡은 책임을 센다.

 

클래스 이름은 해당 클래스 책임을 기술해야 한다.

클래스 이름이 모호하다면 필경 클래스 책임이 너무 많아서다.

 

단일 책임 원칙

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

클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.

 

책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. 더 좋은 추상화가 더 쉽게 떠오른다.

 

SRP는 객체 지향 설계에서 더욱 중요한 개념이다. 또한 이해하고 지키기 수월한 개념이기도 하다.

하지만 이상하게도 SRP는 클래스 설계자가 가장 무시하는 규칙 중 하나다.

 

소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다.

 

문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. '깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않는다.

 

규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다.

 

큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 시스템은 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.