클래스는 코드가 모이는 단위이면서 변경의 단위이기도 하다. 그래서 클래스를 어떻게 구성하느냐에 따라 코드를 읽는 흐름과 수정할 때의 위험이 달라진다. 이 장에서 말하는 핵심은 단순하다. 클래스는 작아야 하고, 하나의 책임에 집중해야 한다.
클래스의 구성
자바 클래스는 보통 위에서 아래로 추상화 수준이 내려가도록 배치한다. 정적 공개 상수, 정적 비공개 변수, 비공개 인스턴스 변수 순으로 변수를 두고, 공개 메서드 아래에는 그 메서드가 사용하는 비공개 메서드를 가깝게 둔다. 이렇게 배치하면 독자는 공개 동작을 먼저 보고, 필요한 만큼만 세부 구현으로 내려갈 수 있다.
캡슐화는 기본적으로 내부 구현을 숨기는 방향을 택한다. 변수와 유틸리티 함수는 가능하면 공개하지 않는 편이 좋다. 다만 테스트나 같은 패키지의 협력이 필요한 경우처럼 이유가 분명하다면 제한적으로 열어둘 수 있다. 중요한 것은 무심코 공개 범위를 넓히지 않는 것이다.
작은 클래스와 단일 책임
함수의 크기는 줄 수로 어느 정도 감을 잡을 수 있지만, 클래스의 크기는 책임의 수로 봐야 한다. 클래스 이름이 모호해지거나 Processor, Manager, Super 같은 단어에 기대게 된다면 여러 책임이 섞였을 가능성이 크다. 클래스를 설명할 때 “그리고”, “또는”, “하지만”이 자주 필요하다면 나눌 시점이다.
단일 책임 원칙은 클래스가 변경될 이유를 하나만 가져야 한다는 원칙이다. 예를 들어 SuperDashboard가 화면 컴포넌트도 관리하고 버전 정보도 추적한다면 두 가지 이유로 변경된다. 버전 정보는 별도 클래스로 분리하는 편이 자연스럽다.
public class Version {
public int getMajorVersionNumber() { ... }
public int getMinorVersionNumber() { ... }
public int getBuildNumber() { ... }
}작은 클래스가 많아지면 전체 구조를 보기 어렵다고 느낄 수 있다. 하지만 큰 클래스 하나에 여러 책임이 얽혀 있는 편이 더 위험하다. 잘 나뉜 클래스는 이름과 위치만으로도 역할을 설명하고, 변경이 필요한 지점을 좁혀 준다.
응집도
응집도는 클래스의 메서드와 변수가 얼마나 밀접하게 연결되어 있는지를 말한다. 메서드들이 같은 인스턴스 변수를 자주 사용한다면 응집도가 높다. 반대로 어떤 메서드는 이 변수만 쓰고, 다른 메서드는 전혀 다른 변수만 쓴다면 서로 다른 책임이 한 클래스에 섞였다는 신호일 수 있다.
큰 함수를 작은 함수로 나누다 보면 일부 함수가 특정 변수 묶음에만 의존하는 모습이 드러난다. 이때 억지로 한 클래스 안에 붙들어 두기보다 새로운 클래스로 분리하면 구조가 더 선명해진다. 응집도가 낮아진 클래스는 쪼개야 한다.
변경하기 쉬운 클래스
깨끗한 시스템은 변경이 생겼을 때 영향을 받는 범위가 작다. 요구사항은 계속 바뀌므로, 클래스가 구체적인 구현에 직접 매달릴수록 변경 비용이 커진다. 인터페이스와 추상화를 사용하면 세부 구현의 변화를 바깥으로 새어나가지 않게 만들 수 있다.
예를 들어 포트폴리오가 주가를 계산해야 할 때, 변동이 잦은 외부 API에 직접 의존하면 테스트도 어렵고 변경에도 취약하다. 대신 필요한 동작을 인터페이스로 정의한다.
public interface StockExchange {
Money currentPrice(String symbol);
}Portfolio는 구체적인 TokyoStockExchange가 아니라 StockExchange에 의존하도록 만든다. 그러면 테스트에서는 항상 100달러를 반환하는 가짜 거래소를 넣을 수 있고, 실제 운영에서는 도쿄 거래소 구현을 넣을 수 있다.
이런 구조는 결합도를 낮추고 테스트 가능성을 높인다. 동시에 고수준 정책이 저수준 구현에 휘둘리지 않게 하므로 DIP에도 가까워진다.
마무리
클래스를 작게 나누는 목적은 단순히 파일 수를 늘리는 데 있지 않다. 책임을 분명히 하고, 변경 이유를 좁히고, 읽는 사람이 한 번에 이해할 수 있는 단위로 코드를 정리하기 위해서다. 클래스가 커지고 이름이 흐려진다면 책임을 다시 살펴봐야 한다.
다음장으로 11장