[Design Pattern] Decorator Pattern 데코레이터 패턴에 대해 알아보자!

서론 

디자인 패턴 중, 데코레이터 패턴은 이전 건수님께서 프로젝트 적용 시 해당 패턴을 이용해 구현을 하시고 이에 대해 기술블로그까지 작성과 리뷰를 해주신 적이 있어서 이 패턴에 대해 당시 찾아봤던 경험을 가지고 있다. 

 

혹시나 궁금하신 분들이 계실수도 있으니, 해당 부분에 대해 링크를 첨부하고자 한다. 

https://zuminternet.github.io/vote-architecture/

OOP 기반 선착순 투표 시스템 아키텍처

 

내용이 정말 좋아서 관심있으신분들은 한 번씩 읽어보셔도!? 좋을 것 같다. 

 

위와 같은 이유들로 데코레이터 패턴에 대해 한번 정리를하여 남겨보고자 한다. 

본론 

디자인 패턴을 알아보기 전, SOLID 원칙 중, OCP에 대해 살펴보고자 한다. 

 

OCP ( Open-Closed Principle ) 개방폐쇄 원칙 
클래스는 확장에서는 열려있어야하지만, 변경에는 닫혀있어야 한다. 
즉, 기존 코드는 건드리지 않은채로 새로운 기능을 추가할 때 급변하는 주변 환경에 잘 적응하는 유연하고 튼튼한 디자인을 만들 수 있다.

 

자 그러면, 데코레이터 패턴의 정의를 살펴보도록 하겠다. 

 

데코레이터 패턴 ( Decorator Pattern ) 
객체에 추가 요소를 동적으로 더할 수 있다. 
데코레이터를 사용하면 서브클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있다. 

 

해당 그림을 살펴보자 

 

Decorator는 Componen를 참조할 변수가 있다. 

 

Decorator의 생성자에서 Component를 참조할 변수를 초기화할 수 있도록 전달을 해주고, 

 

Decorator 클래스는 자신의 메서드를 실행하고 Component를 참조하는 변수를 통해 다른 Decorator에 접근해 메서드 실행이 가능하다.

 

그렇다면 위와 같은 주제를 통해, 한번 구현을 해보았다. 

 

여기서 Beverage가 Component로 사용이되고 첨가되는 재료들은 Decorator이다.

 

이제 음료들은 Beverage를 상속받고, 재료들을 추가하고자 한다. 

 

해당 구현한 내용들은 아래 링크에 담겨져 있다. 

https://github.com/JoeCP17/spring-study/tree/master/disignPattern/src/main/java/com/example/disign/decoration

GitHub - JoeCP17/spring-study: 스프링 TIL 저장소

 

 

 

위 구현한 내용은 다음 그림과같은 구조로 이뤄져 있다. 

 

Beverage를 생성한 후, Decorator로 Beverage를 포장한 후 Decorator로 다시 포장한다고 생각하면 된다.

 

해당 그림만 보더라도 OCP원칙이 지켜지며 확장에는 열리고 변경에는 닫히며 진행됨을 확인할 수 있었다. 

 

데코레이터 패턴(Decorator Pattern)은 상속과 달리 동적으로 기능을 유연하게 확장할 수 있는 강점이 있다.

 

상속을 통한 기능 확장 및 수정은 정적일 수밖에 없지만 해당 패턴을 사용하게 되면 데코레이터를 자유롭게 할 수 있다. 

 

결론

데코레이터 패턴은, 자신이 가지고있는 컴포넌트의 메서드를 호출한 결과에 새로운 기능을 더하고 데코레이터를 제한 없이 사용할 수 있기에, 기능 확장성에서는 매우 유용해 보인다.

 

하지만, 데코레이터를 통해 이뤄지기에 필요한 데코레이터에 대해서는 계속 생성을 해줘야 하기에, 적다면 상관없겠지만 무수히 많아진다면 코드 복잡성 측면에서의 단점을 가질 수 있기에, 기능확장에 대한 요소가 어느 정도 절충안이 된다면 사용해 보면 좋을 것 같단 생각이 들었다.