🚩 깨끗한 클래스를 작성하는 방법
"도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" (p.177)
💻 클래스 체계
표준 자바 관례
1. static, public 상수
2. private 변수
3. private 인스턴스 변수
4. public 함수
5. private 함수캡슐화
- 변수와 유틸리티 함수는 가능한 private으로 하는 것이 낫다.
- 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
💻 클래스는 작아야 한다
- 클래스가 맡은 책임을 최소화하라.
- 큰 클래스 몇 개가 아닌 작은 클래스 여럿으로 이루어진 시스템이 더 바람직하다.
- 메소드 개수가 적다고 책임이 적은 것이 아니다.
- 클래스가 맡은 책임을 클래스 이름에 간결하게 표현할 수 있어야 한다.
단일 책임 원칙 (SRP)
- 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다.
- 책임 == 변경할 이유
- 변경을 가할 때, 직접 영향이 미치는 컴포넌트만 이해하고 수정하도록 설계하라.
응집도 (Cohesion)
- 응집도: 클래스의 변수와 메소드가 논리적으로 서로 의존하는 정도
- 클래스의 응집도는 높아야 한다.
- 응집도가 낮은 클래스는 별도의 클래스로 분리해야 한다.
응집도를 유지하면 작은 클래스 여럿이 나온다
- 몇몇 변수를 몇몇 함수가 사용한다면 그 변수들을 새 클래스 인스턴스 변수로 승격하라.
- 응집도가 낮아지면 변수와 함수를 독자적인 클래스로 분리하라.
- 변경 시에는 프로그램의 작동을 검증하는 테스트를 반드시 병행하라.
💻 변경하기 쉬운 클래스
"이상적인 시스템은 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다." (p.188)
- OCP(Open-Closed Principle): 확장에 개방적이고 수정에 폐쇄적이어야 한다.
- 클래스를 작게 분리해서 수정할 코드를 최소화하는 것이 바람직하다.
변경으로부터 격리
- 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리하라.
- 상세한 구현에 의존하지 않도록 시스템 결합도를 낮춰라.
- 추상화된 인터페이스에 의존하도록 해서 실제 작동하는 방식 등의 구체적인 사실을 모두 캡슐화하라.
📝 느낀점
클래스도 함수와 마찬가지로 하는 일을 하나의 논리적인 일로 단순화하는 것이 중요하다는 것을 배웠다. 단순히 코드 라인 수를 줄이는 것이 아니라 책임을 최소화하는 것이 깨끗한 코드를 만들고, 깨끗한 코드는 안정적이고 유연한 서비스를 제공하게 된다.
이전에 했던 프로젝트에 외부 API를 클래스로 불러와서 구현한 부분이 있었는데, 아주 엉망진창이었다. 본문에서 하지 말라는 짓을 다 했던 것 같다. API를 감싼 클래스를 만들긴 만들었는데, 추상화를 한 것이 아니라 작동 방식을 그대로 노출시켜버렸고, 호출 함수에서 API 관련 에러를 처리하게 하였으며, 클래스 하나가 모든 일을 다 처리했다.
그래서 이 책을 계속 읽으면서 남이 깨끗하게 바꿔 놓은 코드를 보는 것도 중요하지만, 내가 직접 짠 코드를 리팩터링하는 경험이 정말 많이 필요할 것 같다는 생각이 들었다. 저자가 리팩터링한 코드는 정말 깔끔하고 가독성이 좋아서 보면 기분이 좋아지는데, 여러모로 동기부여가 되어 주는 것 같다.
