구조 관련 디자인 패턴 > 컴포짓 패턴(Composite Pattern)

https://inf.run/6Shr

코딩으로 학습하는 GoF의 디자인 패턴 - 인프런 | 강의

 

 

컴포짓 패턴

구조관련 디자인 패턴.

 

그룹 전체와 개별 객체를 동일하게 처리할 수 있는 패턴.

 

클라이언트 입장에서 ‘전체’나 ‘부분’이나 모두 동일한 컴포넌트로 인식할 수 있는 계층 구조를 만든다.

 

트리 구조를 구성해야하는 제한이 있다.

하지만 트리구조로 표현할 수 있는 게 일상 생활에 많기 때문에 트리구조라는 제한이 있더라도 컴포짓 패턴으로 작성되는 경우가 많다.

 

 

컴포짓 디자인 패턴을 적용하기 전

가방안에 아이템의 가격을 구하고 싶을 경우.

가격을 계산하는 명령을 할때 가방 또는 가방안에 가방이 있다면 그 사실을 클라이언트는 구체적으로 알고 있어야 할까?

 

 

 

 

 

컴포짓 디자인 패턴의 구조는 값을 구할만한 모든 컴포넌트들의 공통적인 인터페이스를 정의한다.

클라이언트는 컴포넌트라는 인터페이스 타입만 보게된다.

 

 

 

 

 

컴포짓 패턴 적용하기

공통된 오퍼레이션을 인터페이스에 두는 것이 중요하다.

예제에서는 겟프라이스라는 메시지를 정의하였고 가방과 아이템 모두 이 기능을 지원해야 한다.

 

컴포짓에 들어와있는 컴포넌트들의 가격을 구하는 로직이,

클라이언트에서 가방쪽으로 옮겨지게 된다.

가격을 구하는 로직이 가방의 책임이 되는 것이다.

이렇게 변경하면 클라이언트가 지나치게 많은 정보를 알 필요가 없다.

 

컴포짓 패턴을 적용하기 전에는 

아이템을 파라미터로 받는 getPrice()와 

가방을 파라미터로 받는 getPrice()를 

클라이언트에 따로 정의했어야 했다.

하지만 컴포짓 패턴을 적용하면 클라이언트는 컴포넌트만을 의존하여,

컴포넌트를 파라미터로 받는 getPrice()만을 정의한다.

 

변수의 타입을 설정할 때 가능한 추상적인 타입을 사용하는 습관을 갖는 것이,

위와같이 메시지 2개를 정의할 것을 1개로 공통되게 사용할 수 있게되기 때문에 좋다.

 

코드를 개선한 결과 클라이언트는 구체적인 정보를 알 필요가 없다.

가격을 어떻게 구할지는 컴포짓 객체가 알아내고 또는 리프에 해당하는 컴포넌트 객체가 알아낸다.

클라이언트에서는 컴포넌트라는 인터페이스에 단순히 위임만 한다.

 

 

컴포짓 패턴의 장점

1. 복잡한 트리 구조를 편리하게 사용할 수 있다.

최상위 혹은 리프등 어느 노드인지 상관없이 컴포넌트라는 공통된 인터페이스를 이용하여 구현하고 있다면 클라이언트 입장에서 그 인터페이스를 기준으로 사용하기만 하면 되기 때문에 편리하다.

2. 다형성과 재귀를 활용할 수 있다.

3. 클라이언트 코드를 변경하지 않고 새로운 엘리먼트 타입을 추가할 수 있다.

컴포짓 패턴의 단점

트리를 만들어야 하기 때문에, 공통된 인터페이스를 정의하는 과정에서 지나치게 일반화해야 하는 경우가 생길 수 있다.

 

예를 들어 컴포넌트 타입이 가방이냐 아이템이냐 확인하는 경우같이 런타임 시 타입을 체크하는 경우가 빈번할 때.

그 때는 특정한 디자인패턴에 종속적으로 코드를 작성하는 것이 아닌가 한번쯤 의심해야봐야한다.

 

 

 

 

 

 

https://refactoring.guru/ko/design-patterns/composite

Composite