[디자인패턴] 헤드퍼스트 디자인패턴 Chap.3 (Feat. 데코레이터 패턴)

패턴이 나오게 된 문제 상황

예를 들어 카페에서 판매하는 음료를 표현하고자 할 때,

커피1, 커피2, 커피3, 커피4 이렇게 종류가 있고, 들어갈 추가 요소가 우유, 두유, 모카, 휘핑크림 등이 있다고 하였을 때

위에 말한 요소들의 조합을 모두 서브 클래스로 만든다면 4*2^4 = 64개의 서브 클래스가 생길 것이다. 만약 우유나 두유 등 추가 요소를 한번만 넣거나 마는 것이 아닌 2번 이상 넣을 수 있다고 가정하면 더욱 경우의 수가 늘어날 것이다. 

 

Adding Boolean Variables 로 해결한 경우

앞서 말한 예시에서의 추가 요소에 대한 boolean 변수를 만들어 해결하는 방식이다

이러한 경우 음료 클래스에서의 cost() 구현하고 하위 클래스는 cost()를 오버라이드하여 사용한다.

=> 추가 요소 가격이 바뀔 때마다 기존 코드 수정 필요

추가 요소 종류가 많아지면 새로운 메소드(getter,setter,...)와 변수 추가 해야하고, cost()도 수정 필요

추가 요소의 일부가 필요 없는 서브 클래스도 존재 할 수 있는데 이 경우에도 필요 없는 추가 요소들을 전부 상속받게 된다.

추가 요소를 2번 이상 넣는 등을 표현하지 못함

 

등의 문제가 있기에 데코레이터 패턴이 등장

 

OCP : 확장 OK, 기존 설계, 코드 수정 No

 

OCP를 다 적용하면 너무 복잡해지고 성능 저하 => 충분히 적용할만한 부분인 곳에 적용

 

 

Decorator Pattren

 

 

Decorator Pattern을 적용한 경우

 

DarkRoast 객체가 있을 때

모카를 추가하고자 하면 이를 Mocha 객체로 감싸고 

여기에 휘핑을 추가하고자하면 이걸 또 Whip객체로 감쌈

 

기존의 객체를 수정하는 것이 아닌 기존의 객체를 wrapping, 여러번 가능

=> 객체에 추가 요소 동적으로 더할 수 있고, 서브클래스를 만들 때보다 유연하게 확장 가능

 

Decorator 패턴을 사용하는 경우

객체의 책임이나 행동이 동적으로 바뀌어야할 때

기존 클래스의 서브 클래스 만드는 것이 불가능하거나 비효율적일 때

자잘한 크기의 객체들이 많이 등장하게 되는데(단점) 이를 수용가능할 때

...

 

 

 

 

 

Decorators have the same super type as the objects they decorate. 

 

부모 클래스를 상속받으면서 부모클래스를 가리킴 

Composite 패턴과 유사 

Composite 패턴인 경우 여러개를 가리킬 수 있기에 * 

Decorator 패턴인 경우 1

 

상속 관계가 없어도 Concrete 가리킬 수 있음

 

Recursive Composition

상속관계가 필요한 이유? 상속하지 않으면 한번은 가능한데 2번은 안됨

ex) ConcreteClass<-ConcreteDecoratorA (가능) 

 ConcreteClass<-ConcreteDecoratorA <-ConcreteDecoratorB (불가능)

 

 

대표적인 예시 Java I/O

 

FileInputStrean <-BufferedInputStream <- LineNumberInputStream

 

 

Decorator 패턴을 모르고 보면 직관적이지 않아 내용을 파악하기 어려운 단점이 있음

 

 

유사한 패턴

Strategy 패턴은 기존의 객체에 수정이 가해짐

Adapter 패턴은 subject가 다른 인터페이스를 연결

Proxy 패턴은 공통된 인터페이스

 

Decorator 패턴은 공통된 인터페이스와 호환되지만 더 향상된 기능을 제공할 수 있음