데코레이터(Decorator) 패턴

케이크에는 여러 종류가 있다.

크림 케이크, 딸기 케이크 등등 다양한 장식(데코레이터)에 따라 케이크의 명칭이 달라진다.

아무것도 장식(데코레이터)하지 않은 케이크를 스펀지 케이크라고 한다.

 

오브젝트(객체)에도 이런 케이크와 비슷한 경우가 있다.

• 중심이 되는 객체인 스펀지 케이크
• 이 스펀지 케이크에 장식이 되는 기능을 하나씩 추가하면 목적이 더욱 뚜렷한 객체가 된다.

데코레이터 패턴은 오브젝트에 장식(데코레이터)을 해 나가는 디자인 패턴이다.

 

GitHub - kkoon9/Java-Design-Pattern: Java 언어로 배우는 디자인 패턴 입문 예제 코드

Decorator 패턴의 등장인물

Component의 역할 - Display

기능을 추가할 때 핵심이 되는 역할이다.

스펀지 케이크에 해당한다.

Component의 역할은 스펀지 케이크의 인터페이스(API)만을 결정한다.

ConcreteComponent의 역할 - StringDisplay

Component 역할의 인스턴스(API)를 구현하고 있는 구체적인 스펀지 케이크다.

Decorator(장식자)의 역할 - Border

Component와 동일한 인터페이스(API)를 가지며, 또한 이 Decorator 역할이 장식할 대상이 되는 Component 역할도 가진다.

이 역할은 자신이 장식하고 있는 대상을 알고 있다.

ConcreteDecorator(구체적인 장식자)의 역할 - SideBorder, FullBorder

Decorator를 구현하는 역할을 한다.

투과적인 인터페이스(API)

데코레이터 패턴에서는 장식과 내용물을 동일시하고 있다.

• 장식 : Border 클래스
• 내용물 : Display 클래스

장식을 사용해서 내용물을 감싸도 인터페이스(API)는 전혀 감출 수 없다.

getColumns, getRows, getRowText, show라는 메서드는 다른 클래스에서 볼 수 있다.

이것을 인터페이스(API)가 ‘투과적’이라고 한다.

인터페이스가 투과적이기 때문에 컴포지트 패턴과 닮은 재귀적인 구조가 등장한다.

구조만 유사할 뿐 목적은 다르다.

데코레이터 패턴은 기능을 추가해가는 것에 집중한다.

 

데코레이터 패턴은 내용물을 변경하지 않고 기능을 추가할 수 있다.

데코레이터 패턴에서는 위임을 사용하고 있다.

‘장식'에 대한 요구(메소드의 호출)는 그 ‘내용물'에 떠넘겨(위임)진다.

예로, 위 프로그램에서 SiderBorder의 getColumns는 display.getColumns()을 호출하고 있다.

데코레이터 패턴에서 사용되는 위임은 클래스 사이를 느슨하게 결합한다.

소스를 변경하지 않고 오브젝트의 관계를 변경한 새로운 오브젝트를 만들 수 있다.

java.io 패키지와 데코레이터 패턴

java.io는 입출력을 실행하기 위한 패키지다.

여기에서는 데코레이터 패턴이 사용된다.

우선 다음과 같이 하면 파일에서 데이터를 읽어 들이는 인스턴스를 만들 수 있다.

Reader reader = new FileReader("example.txt");

또한, 다음과 같이 하면 파일에서 데이터를 읽어 들일 때 버퍼링이 실행된다.

Reader reader = new BufferedReader(
                    new FileReader("example.txt")
                );

위 코드를 보면 알 수 있다시피 예제 프로그램과 흡사하다.

 

데코레이터의 단점은 매우 유사한 성질의 작은 클래스가 많이 만들어진다는 점이다.

관련 패턴

• Adapter 패턴
• Strategy 패턴