데코레이터 패턴은 어떻게 해서 등장하게 된 것일까?

상속을 지양하고 포함관계와 다형성을 활용하기 위해 등장했다

자바에서는 상속이 있다. 상속이란? 코드를 재사용하기 위함, 하위 클래스가 상위 클래스의 코드를 재활용하는 것

하지만, 상속에는 다음과 같은 문제점이 있다. 하위 클래스에서 상위 클래스의 멤버를 사용하는 경우 상위 클래스의 정보를 정확하게 인지해야한다. 이는 하위 클래스를 통해 상위 클래스로 접근할 수 있는 경로를 만들기 때문에 캡슐화 파괴 발생 가능하다

물론, 단순하게 확장만 하기위해 상속을 사용하는 경우에는 위의 문제와 관련이 없다. 예를들어서, Template Method 패턴이 있다.

또 이 문제를 방지하기 위해 등장한 클래스 타입 Sealed Class가 있다. Sealed Class란? 자손의 개수를 제한하는 클래스이다. 즉, 외부에서 함부로 클래스 추가 못하게 한다. 이는 State 패턴과 유사하다

다시 본론으로 돌아와서, 상속은 코드 재사용성을 높이지만 캡슐화 파괴의 여지가 있기 때문에 이를 해결할 방안을 찾아야한다.

클래스 간의 관계는 크게 두 가지로 구분된다. 첫 번째는 상속관계이고 두 번째는 포함관계이다.

그럼 포함 관계로 코드를 재사용할 순 없을까?? 물론 사용할 수 있다. 하지만 포함 관계의 경우 다형성을 활용할 수 없는 단점이 있다.

다형성이란 여러가지 타입을 표현할 수 있는 것을 의미한다. 좀 더 명확하게 설명하자면, 부모 타입 참조 변수로 자손 타입 인스턴스를 참조해서 사용하는 것이다.

다형성을 활용하면 코드 자체가 변경 주기가 낮고 확장이 용이하다. 즉, OCP를 적용한 코드라고 할 수 있다. 예를들어 자바의 다양란 컬렉션 타입에서 이터레이터를 생성해서 사용하는 코드를 생각하면 바로 이해할 수 있다.

즉, 다형성을 적용하기 위해 상속을 활용한다. 이때 해당 상속은 다형성을 위해 사용된 기법이라는 것을 명심해야한다. 즉, 코드를 재사용하기 위한 기법이 아니기 때문에 하위 클래스에서 상위 클래스의 정보를 알 필요가 없고 서로 코드가 섞일 여지도 없다. 단지 상위 클래스 행세를 할 수 있게 해주면된다.

위에서 볼 수 있듯이 이미 데코레이터의 핵심 개념이 등장했다. 껍데기가 알맹이 행세할 수 있게 만든 구조이다. 즉, 상속과 포함을 동시에 처리한 데코레이터 패턴이 등장했다.

결론, 코드 재사용으로서 사용하는 상속은 캡슐화 파괴할 수 있다. 이를 막고자 데코레이터 패턴이 등장했다(상속과 포함을 동시에 구현 - 상속 : 다형성, 포함 : 코드 재사용)