[객체지향 생활체조 원칙] 규칙 6. 모든 엔티티를 작게 유지한다

모든 엔티티를 작게 유지한다

 이 원칙에서 칭하는 엔티티는 클래스, 패키지를 통틀어 업무적 구분을 갖는 단위를 의미한다. '작은 엔티티' 라고 판단할 수 있는 대략적인 기준은 다음과 같다.

50줄 이하의 클래스
10개 이하의 파일을 갖는 패키지

숨은 의미

 엔티티를 작성할 때 하나의 목적을 염두하고 설계하라는 의미이다. SOLID 원칙중 '단일 책임 원칙' 과도 상통한다. 먼저 클래스의 크기를 줄여 분리하기 시작하면, 작은 역할을 하게 될 것이다. 이 때 작은 역할을 통해 이루려는 하나의 목적을 도출할 수 있다. 그 목적을 이루기 위한 클래스들을 모아 패키지로 구성하면 된다.

패키지와 파일이 많은 것은 나쁜게 아니다

 이 원칙을 지키기 어려운 가장 큰 원인은, 패키지를 새로 만들고 파일을 새로 만드는 행위에 대한 부담감을 가지고 있기 때문일 것이다. 패키지에 계층을 추가하고, 파일을 일정한 패턴으로 모아서 관리하려면 도메인에 대한 충분한 고민이 필요하다.

 

 패키지의 계층을 추가하고, 클래스 구조에 패턴(디자인 패턴 뿐만 아니라, 프로젝트에서 통용되는 도메인 기준의 약속)을 주려면 프로젝트 구성원들이 설계에 대해 충분히 고민해야 한다. 심도깊은 토론을 통해 부족한점을 메꾸고 최적의 설계를 도출해 내야한다.

 

 처음부터 완벽한 구조설계가 나올 수는 없다. 리팩토링을 통해 클래스를 분리하고 새로운 관리체계를 만들어내면 된다. 클래스 분리를 두려워하지 말자. 미래에 수만라인의 메소드에서 발생하는 오류의 원인을 찾아내느라 밤을 새는 일을 만드는 것 보다는 훨씬 낫다.

마치며

 프로젝트의 계층구조를 설계할 때는 항상 패키지를 먼저 설정하고 그 이후에 클래스를 집합시키는 순서로 구성했었다. 그런데 클래스를 먼저 쪼개고 특정 목적을 향하는 역할들을 모아 패키지를 구성하는 상향식으로 생각할 수 있다는 방향이 신선한 것 같다. 도메인 모델 클래스의 역할과 책임을 기반으로 프로젝트의 구조를 구성해 나가면 보다 유연한 솔루션을 개발할 수 있을 것이라는 생각이 든다.