[이 글은 Head First Design Patterns을 공부하면서 작성한 포스팅이라 책의 내용과 유사한 부분이 상당히 많이 있습니다. 저작권에 걸린다면 바로 삭제하겠습니다.]
데코레이터 패턴은 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방식을 제공한다
라고 서술 하고 있습니다.
어떻게 보면 객체지향의 확장성에 대해서 제대로 제시하는 디자인 패턴이 아닌가 싶다.
클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다.
기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있도록 하는게, 과연 가능하단 말인가? 객체는 어떻게 골라야 하지?
이 책에서는 모순된 말 같지만 직접 코드를 수정하지 않고도 코드를 확장할 수 있는 기법이 있다고 한다.
알아보자!
포스팅의 제목이 Decorate Pattern이다. Decorate라는 것은 장식하다! 라는 뜻이다.
객체안에 상속 쪽으로 넣지 않고 장식을 하면 코드의 수정없이 클래스에 날개를 달 수도, 다리를 달 수도 있다.
책에서 말하는 것은 커피를 주문 할 때, 휘핑크림 추가와 모카추가라고 했을 때!
보통은 커피 클래스안에 휘핑크림의 요소와 모카의 요소를 넣기 마련이다.
그러나 데코레이터 패턴은 휘핑크림 클래스 안에, 모카클래스를 넣고, 모카 클래스 안에 커피 클래스를 넣는 방법이다.
결국, 휘핑크림도 음료수 클래스를 상속 받아 만드는 것이고, 모카도 음료수클래스를 상속 받아 만들고, 커피도 음료수를 상속받아 만들면 되는 것.
Beverage beverage1 = new Coffee();
beverage1 = new WhipCream(beverage1);
beverage1 = new Mocha(beverage1);
이런식으로 구현을 하면 결국 beverage1이 모든 것을 갖고 있는!
확장성을 위해서 사용하는 것이 아니라면 상당히 오버해드가 커질 수도 있고, 할게 많아지는 것같다.
물론 많이 유명한 팩토리와 빌더 디자인 패턴도 있지만,
한 걸음, 한걸음 나아가 보자고요!
근데, 객체의 class 종류로 이게 커피인지, 물인지 알 수 없다는 단점이 있다. 커피를 할인하는 경우도 그와 같은 경우에 들어가겠죠?
예를들어 커피에 휘핑크림은 무료고, 다른 음료의 휘핑크림은 유료일 때, 코드의 수정을 피할 수 없다. 그럼 if나 switch를 사용해서 나눠야 하고, 유지보수가 힘들어진다는 단점이 있다.
