디자인 패턴이란?
유래반복된 문제에 대한 재사용 가능한 해결책
90년대 GoF(Gang of Four)로 불린 4명의 프로그래머가 쓴 책 [Design Patterns: Elements of Reusable Object-Oriented Software, Pearson Education]에서 유래
데코레이터 패턴이란?
기존 객체의 동작을 동적으로 증강시키는 구조적 디자인 패턴
객체와 클래스를 유연하고 효율적으로 유지하면서, 더 큰 구조로 조합하는 방법을 설명하는 패턴
어떠한 문제의 해결책인가?
문제점
- 어떤 클래스의 동작 추가를 상속으로 하다보면, 상속의 정적인 특성으로 인해 코드가 엄청나게 부풀려질 수 있다.
예시
이벤트 발생에 대한 이메일 알람을 보내는 Notifier 라는 클래스를 지닌 라이브러리를 생각해보자. 그리고 이 라이브러리를 사용하여 프로그램을 개발한 개발자 홍길동을 생각해보자.
홍길동은 자신의 프로그램 사용자들이 이메일 뿐 아니라 다양한 곳에서 알람을 받길 원한다는 것을 깨닫고 이를 상속으로 해결하였다.
그러나 사람들은 점점 더 많은 것을 요구한다... 한 곳에서 뿐 아니라 다양한 곳에서 한 번에 알람을 받길 원하는... 만약 언어가 다중 상속을 지원하지 않는다면 자식 클래스의 수는 걷잡을 수 없이 늘어날 수 있다.
해결책
is 가 아닌 has: 데코레이터 패턴의 핵심 아이디어
즉, 상속이 아닌 Aggregation 이나 Composition 을 사용하여 기본이 되는 서비스 메서드를 제공하는 객체(위 예에선 Notifier의 인스턴스)를 참조 값으로 가지고 있는 'Helper' 객체를 통해 수정하는 것.
- Aggregatoin: 객체 A가 객체 B를 포함하고 있으며, 각 객체의 생명주기는 무관하다.
- 예시: Person과 Address의 관계
- Composition: 객체 A가 객체 B로 이루어져 있으며, 각 객체의 생명주기는 연관되어 있다.
- 예시: Car와 Engine의 관계
구조
데코레이팅(혹은 래핑)할 객체와 동일한 인터페이스를 지닌 베이스 데코레이터를 생성한 후, 필요에 따라 베이스 데코레이터를 상속하여 확장하는 형태. 이후 클라이언트는 원하는 기능을 동적으로 데코레이팅하여 사용할 수 있다.
위 예시에서 상속을 사용해서 발생했던 코드 증대의 문제는 데코레이터를 사용하여 아래 그림과 같이 해결될 수 있다.
장단점
장점
- 런타임에서 동적으로 객체 동작 확장 가능 -> 상속에 비해 코드량이 줄어듬
- 단일 책임 원칙(SRP)에 부합. 하나의 데코레이터가 하나의 동작을 변경
단점
- 스택 형식
- 특정 래퍼를 제거하기 어려움
- 증강된 동작의 순서를 바꿀 수 없음
적용 가능성
- 객체의 동작 확장이 동적으로 필요하나 해당 객체를 사용하는 코드에서 이슈 발생을 예방하고 싶을 때
final키워드 사용 등, 더 이상 상속이 불가능할 때
