POSA, Whole-Part 패턴

GoF 의 디자인패턴이 상당히 구체적이라면, POSA 의 디자인패턴은 좀 더 범위가 두루둥실하다. 사실, 이 Whole-Part 패턴의 경우 어느 정도 OOP 를 해온 경험이있다면 당연한 이야기에 이름을 붙인 정도라고 볼 수 있다. 가령, 인터페이스 혹은 추상화된 기능을 정의(클래스)하고 각 기능의 위임 역할을 하는 클래스들을 결합하여 사용하는 것은 상식에 가까운 설계이지 않을까? 여기서 추상화된 기능을 정의한 클래스가 Whole 이 되고 위임을 하게된 클래스들이 Part 가 된다.

아울러 GoF 의 디자인패턴에 비해 좀 더 범위가 크다고 했는데, Composite 패턴이 이러한 Whole-Part 패턴의 일종으로 설명되고 있다.

이때, TComposite 가 Whole 이 될 것이고 TLeaf 가 Part 가 된다. 그리고 Composite 패턴의 특성으로 TComposite 또한 TComponent 를 상속 받았으므로 TLeaf (Part) 처럼 취급될 수 있다. 따라서 트리형으로 Whole, Part 를 처리할 수 있으며 동일한 메소드를 가지게 된다.


Whole-Part 패턴은 관계에 따라 크게 세가지 유형으로 분류한다.

assembly-parts 관계 : assembly 가 whole 이고 parts 가 part 에 해당하는 것으로, part 들의 조합이 결정되어있으며 변경되지 않는다. 가령, OSI 7계층 구조를 클래스로 표현하였다면 3계층 클래스는 4계층부터 7계층까지의 클래스들의 조합이 될 것이며 각각의 파트들이 동적으로 추가되거나 삭제될 필요가 없다.

container-parts 관계 : container 가 whole 이고 parts 가 part 에 해당하는 것으로, part 들이 동적으로 추가되거나 삭제될 수 있다.

collection-members 관계 : collection 이 whole 이고 members 가 part 에 해당하는 것으로, part 들을 묶음으로 관리하고 묶어진 part 들은 공통된 인터페이스를 제공한다. 그리고 whole 은 이러한 part 들을 반복하여 접근한다. container-parts 관계의 특수한 경우로 볼 수 있는데 GoF 의 Iteration 패턴을 활용할 수 있다.


그 외 Whole-Part 변형들에 대하여 설명하고 있는데, 개인적으로 패턴이 너무 포괄적이게되면 커뮤니케이션 장점을 훼손시킬 수 있다고 생각한다. 그런면에서 POSA 패턴은 GoF 패턴에 비해 작업자간 커뮤니케이션에 어느 정도 제약(단서 조항)이 필요할 것으로 보인다. 그러나 GoF 에 비해 후에 정리된 패턴들이라 분산 환경과 같은 큰 구조에 적합한 패턴들을 소개하고 있어 상호보완적인 부분이 크다.