Rise Up

가끔 C를 처음 배우고, 객체지향 프로그래밍을 시작한 사람들에겐 주요 키워드가 있다

바로 "Design Pattern" <이하 DP>

그도 그럴것이 절차지향 처음하다가 객체지향을 막 접한 상태에서 DP에 관한 설명이나 책을 보면

"이게 뭔 소리야?", "그냥 이런게 있나보다..." 한다.

그리고 그것이 객체지향 프로그래밍에서 꼭 갖춰야할 한가지 요소로 판단한다.

그래서 객체지향을 막 접한 이들이 DP 서적을 볼 때 

'과연 이해는 하고 있을까?'

'주변의 추천에 의해서 먼저 보는 것인가?'

'저걸 지금 보면 적용할 수 있을 만한 안목이 있을까?'

이런 생각들을 하게 된다.

사실 객체지향적 사고가 천재적으로 뛰어나다면 DP를 따로 공부하지 않아도 된다.

(협업을 위해, 다른이에게 쉽게 자신의 코드를 이해시키기 위해 필요할 뿐..)

GoF의 DP는 객체지향의 전문가들이 모여 자주쓰는 객체지향 설계 방법을 정의해 놓은 것이다.

그뿐이다. 가끔 패턴 맹신론자들이 나와서 DP의 이름을 쉴세없이 나열하면서 설명하면,

'리스코프 치환은 알까?'

'아니 그보다 더 기초적으로 응집도 높은 코드와 결합도 높은 코드의 차이는 알까?' 라는 생각을 하게 된다.

각각의 DP는 홀로 쓰이는 경우가 적기 때문에, 따로따로 공부해봤자

구현에 아름답게 적용할 수 있는 경우는 지극히 적다..

http://www.codeproject.com/Articles/6849/Design-Patterns-Implementation-in-a-Storage-Explor

http://www.codeproject.com/Articles/12183/Design-Your-Soccer-Engine-and-Learn-How-To-Apply-D

[이 글은 Head First Design Patterns을 공부하면서 작성한 포스팅이라 책의 내용과 유사한 부분이 상당히 많이 있습니다. 저작권에 걸린다면 바로 삭제하겠습니다.]

 데코레이터 패턴은 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방식을 제공한다 
라고 서술 하고 있습니다.

 어떻게 보면 객체지향의 확장성에 대해서 제대로 제시하는 디자인 패턴이 아닌가 싶다.

 클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다. 

 기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있도록 하는게, 과연 가능하단 말인가? 객체는 어떻게 골라야 하지? 

 이 책에서는 모순된 말 같지만 직접 코드를 수정하지 않고도 코드를 확장할 수 있는 기법이 있다고 한다.
 알아보자!

포스팅의 제목이 Decorate Pattern이다. Decorate라는 것은 장식하다! 라는 뜻이다. 

객체안에 상속 쪽으로 넣지 않고 장식을 하면 코드의 수정없이 클래스에 날개를 달 수도, 다리를 달 수도 있다.
 
책에서 말하는 것은 커피를 주문 할 때, 휘핑크림 추가와 모카추가라고 했을 때!
보통은 커피 클래스안에 휘핑크림의 요소와 모카의 요소를 넣기 마련이다.

그러나 데코레이터 패턴은 휘핑크림 클래스 안에, 모카클래스를 넣고, 모카 클래스 안에 커피 클래스를 넣는 방법이다.

결국, 휘핑크림도 음료수 클래스를 상속 받아 만드는 것이고, 모카도 음료수클래스를 상속 받아 만들고, 커피도 음료수를 상속받아 만들면 되는 것.

Beverage beverage1 = new Coffee();

beverage1 = new WhipCream(beverage1);

beverage1 = new Mocha(beverage1);