클래스 체계
Class Organization
클래스를 정의하는 표준 자바 관례에 따르면, 추상화 단계가 순차적으로 내려간다.
- 변수 목록
- public static constants (정적 공개 상수)
- private static variables (정적 비공개 변수)
- private instance variables (비공개 인스턴스 변수)
- 함수 목록
- public functions (공개 함수)
- private functions (비공개 함수)
캡슐화
Encapsulation
변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다.
그러나 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.
클래스는 작아야 한다!
Classes Should Be Small!
클래스를 설계할 때도, 함수와 마찬가지로, '작게'가 기본 규칙이다.
클래스 크기의 척도는 클래스가 맡은 책임이다.
단일 책임 원칙
The Single Responsibility Principle
단일 책임 원칙(SRP)은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다.
우리는 수많은 책임을 떠안은 클래스를 꾸준하게 접한다.
바로 소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개이기 때문이다.
우리는 프로그램이 돌아가면 일이 끝났다고 여기고 '깨끗하고 체계적인 소프트웨어'를 고려하지 않는다.
큰 클래스 몇 개가 아니라 단일 책임 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다.
응집도
Cohesion
응집도가 높다 = 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다
응집도를 유지하면 작은 클래스 여럿이 나온다
Maintaing Cohesion Results in Many Small Classes
큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다.
변경하기 쉬운 클래스
대다수 시스템은 지속적인 변경이 가해지고, 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.
- 개방폐쇄원칙, OCP(Open Closed Principle): 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하고, 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는 게 이상적이다.
변경으로부터 격리
시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터, 변경으로부터 잘 격리되어 있다는 의미이다.
- 의존 역전 원칙, DIP(Dependency Inversion Principle): 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다.
📖 느낀점
최근 추상화에 대해서 고민이 많았는데, 이 책을 읽다보면 내가 짜는 코드가 너무 부끄러워진다.
OCP, DIP 같은 원칙들을 항상 고려하면서 코드 한 줄 한 줄을 짜면서 더 생각해보고 더 신중해져야겠다. 언제쯤 내 코드를 자신만만하게 내놓을 수 있을까 싶다.
