[Design Pattern] Decorator Pattern과 Proxy Pattern의 비교

안녕하세요. 지금까지 같이 알아본 디자인 패턴 중 데코레이터 패턴과 프록시 패턴은 유사한 구조를 가지고 있으며 사용하는 방법도 유사하다라는 걸 눈치채신 분들이 있을 것 같습니다. 2개 패턴의 구조는 유사하지만 해결하고자 하는 문제와 방법이 다릅니다.

오늘은 데코레이터 패턴과 프록시 패턴을 비교해보도록 하겠습니다.

데코레이터 패턴과 프록시 패턴

프록시 패턴

proxy pattern, 참고 : https://sourcemaking.com/design_patterns/proxy

먼저 프록시 패턴은 위와 같은 아키텍처로 되어있습니다. Real Object에 대해서 실제로 필요할 때 instance가 생성되고 실제 작업이 진행될 수 있도록 하기 위해 적용되는 패턴입니다.

프록시 패턴에서 Real Object는 Proxy가 감싸고 있으며, Proxy를 통해서 처음 접근 또는 요청이 있을 때 생성이 되어집니다. Proxy는 Client가 적절한 권한이 있는지 검사 하기도하며 client의 요청을 컨트롤합니다.
적절하게 만들어진 Proxy 패턴은 Client가 사용할 때는 해당 Real Object를 만들고 사용하지 않을때는 메모리를 해제하는 등의 작업을 하기도 합니다. 예를 들어 JPA에서 DB에 접근할 때 #find 메서드를 이용하면 즉시 호출 하시만 #getReference를 이용하면 Proxy를 이용하여 실제 query를 실행할 때만 DB를 통해 접근하기도 합니다.

데코레이터 패턴

decorator pattern, https://sourcemaking.com/design_patterns/decorator

데코레이터 패턴은 runtime에 real Object에 기능을 확장하고 싶을 때 사용합니다. 이렇게 분리된 부가기능을 담은 클래스는 중요한 특징이 있습니다. 부가기능 외의 나머지 모든 기능은 원래 핵심기능을 가진 클래스로 위임해줘야 합니다. 핵심기능은 부가기능을 가진 클래스의 존재 자체를 모른다. 따라서 부가기능이 핵심기능을 사용하는 구조가 되는 것입니다.

공통점

class의 구조가 비슷합니다. 둘다 동일한 Interface를 구현합니다. 그리고 Wrapper Class와 real class의 관계가 aggregation 즉, has A 관계를 띄고 있습니다.

차이점

프록시 패턴에서는 Wrapper Class와 Real Class의 관계가 컴파일타임에 정해집니다. 반면 데코레이터 패턴에서는 런타임에 정해지도록 되어있습니다.

그리고 프록시 패턴은 Real Class의 접근에 대한 제어를 목적으로하며, 데코레이터 패턴은 Real Class의 기능에 다른 기능을 추가하는 목적으로합니다.

마무리

결과적으로 데코레이터 패턴은 런타임에 real Object의 메서드의 기능을 추가하고 싶을 때 사용하며 프록시 패턴은 real Object의 접근에 집중하는것을 알 수 있었습니다. 프록시 패턴, 데코레이터 패턴은 각각 포스팅을 했던적이 있습니다. 개별 패턴들의 자세한 구현 방법은 해당 포스팅을 참고바랍니다. 프록시 패턴, 데코레이터 패턴

감사합니다.

참조

https://sourcemaking.com/design_patterns/proxy

https://sourcemaking.com/design_patterns/decorator

https://stackoverflow.com/questions/18618779/differences-between-proxy-and-decorator-pattern