HAMA 블로그

패턴은 추상적인 "의도"를 보다 명확한 의미로 "규정" 을 짓습니다.
패턴을 사용하는 이유와 공부하는 이유는 아래와 같습니다.

- 그로 인해 선배로 부터 값진 경험을 물려 받게 해 줍니다. 
- 그로 인해 의사소통을 원할하게  만들어 줍니다.
- 그로 인해 자신의 생각에 확신을 갖게 합니다.
- 그로 인해 장점과 단점을 드러내 줍니다. 모든 패턴에는 장점과 단점이 있습니다. (모든 기술도 마찬가지)  
- 그로 인해 연관 패턴들과의 계층적 구조를 보여주어 큰 규모에서의 설계를 가능하게 합니다.
- 그로 인해 시야가 넓어집니다. 
- 그로 인해 이름 짓기 능력을 발전 시킬 수 있습니다. 
- 그로 인해 추상화 & 모듈화 능력을 발전 시킬 수 있습니다.

이제 다양한 패턴들에 대한 이름과 의도에 대해서 정리 해 보겠습니다. 

Gof 디자인패턴 

Creational 

Sturctural

Behavioral

켄트백 구현 패턴 

멀티쓰레드 디자인패턴 

POSA-2 (네트워킹) 디자인패턴 

이벤트 핸들링 패턴 

Synchronization Patterns

Concurrency Patterns

POSA-3 (리소스) 디자인패턴 

Resource Acquisition

Resource Lifecycle

Resource Release

메세지 큐 디자인패턴 

마이크로서비스 디자인패턴 

엔터프라이즈 어플리케이션 디자인패턴 

Spring 프레임워크 디자인 패턴  www.baeldung.com/spring-framework-design-patterns

J2EE 프리젠테이션 패턴 

J2EE 비지니스 티어 패턴 

기업통합 디자인패턴 

데이터 모델 패턴

DDD 디자인패턴 

빅데이터 디자인패턴 

메모리 매니지먼트 디자인패턴 

데이타 베이스 디자인 패턴 

React 에서 사용되는 패턴 

패턴매칭 (데이터 분석) 디자인패턴 

크립토 이코노미 디자인패턴 

크립토 보안 디자인패턴 

꼬리에 꼬리를 무는 - 유사 디자인 패턴들 (1/2편)

1. Proxy 패턴 vs Decorator 패턴 

두 패턴 모두 기존에 존재하는 객체의 동일한 인터페이스 (쉽게 말하면 메소드) 를 이용해서 (변경하지 않고서) 다양한 행위를 추가하기 위한 의도가 있다. 즉 a 라는 객체에 doAction() 이라는 메소드가 있으면, 다른 객체에서도 동일한 시그니쳐의 doAction() 메소드를 호출해서 a 의 doAction()을 실행하는 동시에 다른 첨가물을 추가해 준다는거다. 

그럼 두 패턴이 같은거네? 뭐 비슷하다고 할 수 있으나 "의도" 에 미묘한 차이가 있다.
Decroator 는 어떤 추가적인 기능을 제공한다고 치면 Proxy 는 추가적인 컨트롤을 제공한다고 볼 수 있다. 

예를 들어보자

Decorator 는 

a 객체의 doAction 이  "hello" 를 출력하는 것이라면 , 데코레이터 역할의 b 객체의 doAction 에서는 a 객체의 doAction 을 호출하여 "hello" 를 출력하는 동시에 그 위 아래로 "********" 이런것을 추가적으로 처리해 주는 것이다. 즉 주요 기능에 무엇인가능력을 부가해서 추가해주는것이 의도이다. 어떤 메소드의 시작이나 끝에 로깅이나 트랙잭션을 추가해 주는 것 또한 데코레이터라 할 수 있다.

Proxy 는 

a 객체의 doAction이 "hello" 를 현재 로컬에 출력하는 것이라면 , Proxy 역할의 b 객체의 doAction 는 "hello" 를 Remote 컴퓨터로 보내서 출력해주는 역할을 한다. 즉 구현된 내용에 부가 기능을 추가해 주려는게 아니라, 그 주요기능을 다양한 방식으로 컨트롤 해주는 역할이다. 외부로 보낸다든지, lazy initailization 한다든지, 캐쉬된 것을 사용한다든지~

이제 다시 UML 을 보자.

구조는 같다. 다만 객체의 역할이 무엇이냐에 따라 나뉜다는 점을 명심하자.

질문) 

그럼 자바의 Dynamic Proxy 는 프록시 패턴인가? 데코레이터 패턴인가? 

답 : "Dynamic Proxy 기능을 어떤 의도로 사용하냐 에 따라서 달라진다." 

하둡이라는 자바기반의 분산처리 시스템에서 Dynamic Proxy 는 RPC 를 위한 Proxy 로 사용되었으며,
스프링에서는? 아래 읽을꺼리를 참고하라~

읽을꺼리: 자바의 Dynamic Proxy는 프록시 패턴인지 데코레이터 패턴인가? 

읽을꺼리: 하둡(Hadoop) 에서 RPC 구조 

2. Decorator 패턴 vs  Adapter 패턴

자  이제 위에서 데코레이터 패턴에 대해서 알아보았다. 어떤 기능에 추가 기능을 유연하게 추가 시켜주기 위한 의도가 있음을 알 수 있었다. 또한 Proxy 패턴을 알아 보았는데, 그것은 추가 컨트롤을 할 수 있게 도움을 주는 것이 었다. 그럼 Adapter 패턴은 무엇일까? 이름 그대로 생각하면 될 거 같다. 예를들어 우리 나라는 전기를 220v 를 사용하는데 110v 사용하는 나라로 여행을 갈 때면 어댑터가 필요하다.  어댑터 패턴도 마찬가지이다. 다른 누군가 만들어 놓은 어떤 기능을 사용하는데 , 자신의 설계는 그대로 가져가 되  다른 라이브러리를 내부에서 그대로 사용하고 싶을 때가 있다.이때 중간에서 변환을 시켜 준다. 즉 사용해야할 메소드가 methodB() 로 생겼는데, 나는 methodA() 라고 호출 해야 한다고 하자. 그럼 어댑터 객체는 methodA() 제공하고 내부에서 methodB()을 호출해 주면 될 것이다.

즉 데코레이터는 중간에서 기능을 추가해 준다면, 어댑터는 중간에서 인터페이스를 변경 해 줄 뿐이다.

이제 UML 을 보자.

Adaptee 는 변환되야할 타깃객체의 인터페이스를 포함한다. Adapter 객체는 내부에서 Adaptee 의 메소드를 호출하고 있다. 간단히 정리하면  Adapter 는 호출해야할 객체의 터페이스를 중간에서 변경해 주는 목적을 가지고 있다.

구체적인 예는 아래 읽을꺼리를 참고하라~

읽을꺼리: JDBC 와 디자인패턴 - 5.Adapter 패턴 

3,4 편 바로가기 -> http://hamait.tistory.com/869