기본 콘텐츠로 건너뛰기

[펌요약] 자바의 Adapter, Decorator, Façade, Proxy 패턴의 유사점과 차이점


Adapter vs Decorator vs Facade vs Proxy Design Pattern in Java 관련 글이 있어서 간단하게 요약.

Adapter, Decorator, Façade, Proxy 패턴의 유사점은 Composition과 Delegation.

  • Adapter패턴은 interface를 감싸서 호출을 위임. 
  • Decorator는 object를 감싼 동작을 구현. 
  • Façade는 하나 이상의 interface를 감싸고 사용하기 쉬운 중앙 집중된 interface를 제공. 
  • Proxy는 Subject를 감싸고 호출을 위임. 

그.런.데!! 왜 이것들이 다른 패턴인가?! 만약 같은 구조라면, Adapter, Decorator, Façade, Proxy 패턴의 다른 점은 무엇인가? 답은 Intent다.

Adapter 패턴의 주된 목적은 interface 전환(convert)이다. Adapter는 두 개의 컴포넌트가 같이 동작하게 한다. 두 개가 같이 동작하지 않는 것은 두 컴포넌트의 interface가 맞지 않기(incompatible) 때문이다.

Decorator 패턴은 실행 시점에 새로운 기능을 추가한다. 심지어 생성 후에도 object의 기능을 추가할 수 있게(enrich) 한다.

Façade 패턴은 interface 전환도 새로운 기능추가도 아니다. 대신에 간단한 interface를 제공해서 클라이언트가 직접 시스템 내부의 개별 컴포넌트에 접근하게 하는 대신에 Façade를 사용하게 한다.

Proxy 패턴은 Adapter와 Decorator와 아주 비슷하지만, object 접근제어가 목적이다. Proxy는 클라이언트의 직접적인 접근을 막는 대신, 실제 object처럼 동작한다. 그리고 실제 object처럼 동작하고 다른 행동을 하거나 원래 object에 요청을 보낼 수도 있다. Proxy는 이 모든 패턴 중에서 가장 다목적한 패턴이고, 다른 방법으로 사용될 수 있다. 예를 들어, 원격 object와 통신하는 Remote proxy, 비용이 많이 드는 object에 접근을 통제하는 Virtual proxy,  role 기반 object의 접근을 제공하는 Protection proxy, 캐시 object를 반환하는 Caching proxy 등에 사용될 수 있다.



자바에서 Adapter, Decorator, Façade, Proxy 패턴의 다른점은,,


1) Adapter 패턴은 인터페이스를 전환하지만, Decorator는 interface를 전환하지는 않고 단지 원본 object 를 받아들이는 메소드에 전달될 수 있도록 원본 object의 interface를 구현할 뿐이다.

2) Decorator 패턴과 와 Proxy의 패턴의 주된 차이점 중 하나는 Decorator는 절대 object를 생성하지 않고, 항상 존재하는 object에 새 기능을 추가한다. 반면 Proxy는 object가 존재하지 않으면 object를 생성할 수 있다. 준비될 때 까지 실제 object처럼 있다가(stand in place of real object .. and then) 실제 object에 요청을 전달할 수 있다.

3) Decorator 패턴은 여러 decorator를 연결(chaining)해서 여러 기능(feature)을 추가할 수 있고 순차적인 방식으로 기능을 동작시킬 수 있다. 반면 Proxy는 proxy 연결(chaining)을 권하지는 않는다.

4) Façade 패턴을 Decorator와 비교하자면, Decorator 같지 않다고 볼 수 있다. façade는 새로운 동작을 추가하지 않고 단지 interface에 있는 메소드를 호출할 뿐이다. 단지 façade로 제공된다.

5) Proxy나 Adapter 패턴은 특정 interface를 구현한 façade를 요구하지 않는다. 사실, façade는 단순히 개별 서브 시스템 컴포넌트를 내부에 유지하고 (holding), 클라이언트에서 요구한 간단한 동작을 제공한다. 그런 후, 그에 상응하는 서브 시스템의 메소드를 호출하는 class 일 수 있다. 예를 들어, 차(Car)를 façade로 생각할 수 있다. 차에 start() 메소드는 클라이언트가 start() 메소드를 호출 할 때, 각 서브시스템의 engine.start(), wheel.start(), lights.on(), ac.on()등의 메소드가 호출될 수 있다.

UML diagram of Adapter pattern


UML diagram of Decorator pattern



UML diagram of Proxy pattern





UML diagram of Facade pattern


정리하면, 
  • 두 개의 다른 부분을 같이 동작하게 할 Interface로 변환해야 한다면 Adapter 패턴
  • 보안이나 성능, 네트워킹 등의 이유로 실제 object를 숨겨야 한다면 Proxy 패턴
  • 런타임으로 기존 object에 새로운 동작을 추가해야 한다면 Decorator 패턴 – Decorator는 클라이언트 요청에 따라 다른 순서로 동작을 섞어서 적용할 수 있는 유연함을 제공
  • 마지막으로 클라이언트가 복잡한 시스템에 단순하게 접근하게 하려면 Façade 패턴을 사용

댓글