[head first 디자인 패턴] decorator pattern

decorator 패턴이란 Abstract class 를 implements 하면서 

구상 클래스를 원소로 갖는 구상 클래스를 의미한다.

 

이렇게 말하면 무슨 말인지 잘 모를 것이다. 

 

예를 들어 커피샵에서 커피를 산다고 하자. 

모든 커피는 가격을 결정하는 Cost 함수를 가지므로, 

Coffee 라는 추상 클래스를 만들자. (왜냐하면 구체적인 커피 종류마다 가격 다 다르니까 구체 클래스가 아니라 추상 클래스로 만든 것이다)

 

그러면 이제 다양한 구체 클래스인 Espresso, Americano, Moca 등에 대해 생각해보자,

( 구체적인 커피 종류, 즉 실제로 메뉴에 판매하는 종목) 

이 클래스들은 모두 추상 클래스인 Coffee 를 extends 하고있다. 

 

그리고 우리는 각 음료수마다 정해진 가격을 cost 함수에서 return 함으로써 구현을 할 것이다. 

 

그런데, 실제로, 커피샵은 우리는 단일 커피 종류들을 판매하는 것에서 그치지 않는다.

그게 무슨 말이냐하면, 실제로 우리는 샷을 추가한다거나, 버블을 추가한다거나에 따라서 

가격이 달라 질 수 있다. 그런데 만약 이렇게 추가할때, 더해지는 가격이 특정 커피 종류에 상관없이

똑같은 상황이라면

 

"버블을 추가한 에스프레소" 와 "버블을 추가한 모카" 와 같이 클래스를 따로 만들다보면, "버블 추가" 로 인한 가격 향상이라는 알고리즘이 반복되고, 

"버블", "크림", "얼음" 등등 가격에 영향을 주는 첨가물들의 종류가 다양해질수록 

 

첨가물 종류 * 커피 타입 종류 개수의 어마어마하게 많은 클래스들이 생성되고, 

똑같은 알고리즘이 계속해서 반복되기 때문에, 이러한 문제를 해결할 필요가 있다. 

 

여기사 반복되는 알고리즘 이란 "이러한 재료가 추가 된 원래 음료수의 가격에다가 재료 가격을 더한다" 이다. 

 

 

그래서 

 

 

class Moca extends Coffee() {

        Coffee coffee;

 

       int cost() {

         return coffee.cost() + 500;

 

      }

 

} 

 

이렇게 구현하면, 재사용성을 높일 수 있다!

여기서는 상속이 아닌 구성을 사용함으로써, 유연성을 높이고 있다. 

상속을 사용하면, 특정 함수를 똑같이 사용하거나, 아니면 아예 새로운 함수를 만들거나 

이런 극단적인 2가지 경우밖에 존재하지 않는다는 것이 단점이다. 

기존의 함수를 사용하면서도 내용을 더 추가한 형태의 바로 위의 예시에 있는 코드를

구현하기 어렵다는것이 단점이다. 

 

 

 

다만 decorator  패턴을 사용하는 것이 항상 좋은 것은 아니다. 

decorator 의 단점은 바로 구상클래스(여기서는 커피나 첨가물 종류)

의 타입에 의존하는 코드는 오히려 재사용성을 줄일 수 있다는 것이다. 

 

 

위의 코드에서 예시를 들자면, 에스프레소냐 모카냐에 따라 

더해지는 금액이 달라지는 경우에는 decorator 패턴을 적용하면, 

오히려 if 문을 너무 남발하게 될 것 같다. 그렇게 되면 음 그냥 espresso 를 가졌을 경우에 돈을 추가하는 걸

각 구체적인 커피 클래스(에스프레소 모카 등) 의 멤버 함수 코드에 넣는게 나을듯....