패키지 설계의 원칙

이 책에서 설명하는 패키지 설계의 원칙은 '반드시 시켜야하는 규칙이 아니며' 언제나 올바른 방법도 아니다. 오히려 어떤 시스템을 여러 부분으로 나눌 때 고려해야하는 여러 trade-off를 올바르게 하도록 해주는 휴라스틱으로 여기면 좋을 것 같다.

• 이 책에서 말하는 패키지 설계 원칙은 따르면, '기능을 기준으로' 시스템을 나누기 보다는 '자주 변경하는 클래스를 함께 모으고, 변경의 이유가 다른 클래스를 분리시켜' 놓는 것이다.
• 또한 시스템의 고차원 아키텍처와 저차원 세부사항과 분리하고, 고차원 아키텍처를 독립적으로 유지하도록 노력한다.

패키지 릴리즈/재사용 등가 원칙 (Release/Reuse Equivalency Principle; REP)

보통 클래스들은 따로따로 재사용하지 않고, 대개 몇몇 클래스를 한 그룹으로 묶어 함께 재사용한다. 이런 재사용 그룹의 클래스들은 한 패키지 안에 들어가야 한다.

그리고 이 패키지는 그것을 재사용할 사람들이 편하게 사용할 수 있는 방향으로 릴리스되고 계속 유지보수 되어야한다.

• 이 원칙에 따르면, 사람들이 편하게 재사용 할 수 있는 패키지를 만드는 것도 클래스들을 패키지 안에 배치할 때 고려할 기준이다.

공통 폐쇄의 원칙 (Common Closure Principle; CCP)

단 하나의 책임 원칙(SRP)에 따르면 클래스를 변경해야하는 이유가 오직 하나뿐 이어야한다. CCP는 이 원칙을 패키지로 확장한 것이다.

• 패키지의 모든 클래스가 똑같은 종류의 변경에는 똑같이 패쇄되기를 원한다.
• 만약 어떤 것을 변경해야 한다면, 그것 때문에 바꾸어야한 클래스들은 동일한 패키지안에 몰려있기를 원한다.

CCP의 목표는 변경 가능성이 비슷한 클래스들을 하나의 패키지로 묶는 것이다. 변경의 이유가 같은 클래스들은 동일한 패키지에 들어가야한다. 이렇게 되면, 무엇이 변경될 때 의존 관계 구조안에 패키지들 가운데 매우 적은 수만 변경하면 된다.

공통 재사용 법칙 (Common Reuse Principle; CRP)

인터페이스 격리 원칙(ISP)에 따르면 클래스의 클라이언트마다 별도의 인터페이스를 만드는 것이 좋다. CRP는 이 원칙을 패키지까지 확장한 것이다.

• 많은 패키지를 클라이언트로 가지는 패키지는 이것을 모두 책임지므로 그 책임이 막중하다.
• 이 패키지의 변경이 생기면 여기에 의존하는 모든 패키지에 큰 영향을 줄 수도 있다.
• 그러므로 한 클라이언트가 사용하는 클래스들과 다른 클라이언트가 사용하는 클래스들은 최대한 분리해야한다.

서로 다른 클라이언트가 사용하는 클래스들이 한 패키지에 섞여 있을 경우, 패키지 안의 어떤 클래스를 바꾸면 그 변경된 클래스를 사용하지 않는 패키지들까지 그 변경의 영향을 받을 수도 있다.