[컴][디자인패턴] Decorator Pattern

Decorator Pattern / 데코레이터 패턴

출처: Head First Desgin Patterns : 데코레이터 패턴

Head First Design Pattern Chapter 3. Decorator Pattern

언제

• 어떤 class 를 수정하지 않고, 기능을 추가하고 싶을 때 사용할 수 있다.
• 그리고 Unix 의 pipe 같이 연속적으로 사용하면 좋을 만한 구조에 어울린다.

설명

어떤 interface(여기서는 그것을 draw() 라고 하자.)을 가진 class B 가 있다.
그것을 실제로 구현한 class C 가 있다.

이 때 우리는 class B 를 실제로 구현한 sub class 들의 기능을 확장하고 싶다.

즉, 같은 draw() 를 사용하는데, 우리는 우리만의 기능을 추가하고 싶다.

간단하게 우리는 class B를 상속하고 class C 에서 썼던 code 를 모두 copy & paste 하고, 그 다음에 우리가 원하는 code 를 추가할 수 있다.

근데, class C 가 코드가 없는 object 인 library 이면 어떻게 할 것인가? 우리는 code 를 copy 할 수도 없다.


현재의 코드를 고치지 않고 구현을 어떻게 할 것인가?

그럼 우리는 이 때 어떻게 하는가.

간단하다. 우리의 draw() 내부에서 C.draw() 를 호출하면 된다. 그런 경우라면, 우리는 C 를 가지고 있어야 한다.(association)

하지만 우리는 C 의 경우에 대해서만 작업을 할 것이 아니라, 모든 draw() 를 implement 한 녀석들에 대해 이 작업이 가능하게 하고 싶다.

그래서 우리는 C 가 아닌 B 와 association 을 갖는다. 즉, B type 을 memeber 로 가지고 있는 것이다.

여기까지 Decorator class(interface) 를 완성한 것이다. 이제 이 Decorator 를 상속받아서 자신만의 추가적인 기능을 가진 draw() 를 구현하면 된다.

당연히 new 를 할 때 인자로 자신이 원하는 draw() 의 기능을 가진 class 를 parameter 로 넘겨야 한다.


decorator class 가 class B 를 상속하지 않는다 해도 구현에는 문제가 없다. 그런데 왜 class B 를 상속할까.

상속을 하므로써 같은 method 를 가지게 된다. 즉 interface 를 일치시키는 효과가 있다.

그렇지 않으면 내가 만든 class 가 draw() 를 가지고 있다고 보장할 수 없다. 그렇다면 내가 만든 class 를 decorator class 에 parameter 로 사용할 수도 없다.



http://stackoverflow.com/questions/1249506/alternatives-to-decorator-pattern

여기서는 Unix 의 pipe 와 같은 모습이라고 생각하면 좋다고 한다.

input >> (output >> input) >> output