관리 메뉴

HAMA 블로그

꼬리에 꼬리를 무는 - 유사 디자인 패턴들 - (1,2) 본문

디자인패턴

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

[하마] 이승현 (wowlsh93@gmail.com) 2017. 7. 7. 14:06


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


패턴을 공부하거나 할 때 UML 에 집중해서 공부하면 안된다고 생각한다. 구조만을 외우고 구조로 구분을 한 사람은  공부한것을 금방 까먹거나 헤깔려하기 쉽기 때문인데, 이유는 거의 비슷한 구조를 갖춘 패턴들은 정말 많기 때문이다. ( 더 헥깔린것은 동일 패턴이 구조가 다른 경우도 부지기수이다. 의도가 같기 때문. 즉 "의도", "목적" 이 중요하다.) 

아래 구조를 보자.

정말 많지 않나?? 이 구조만 보고 뭘 알 수 있을까? 자신이 Composite 패턴만 공부했다면 , 이러한 구조를 보고 무조건 "컴포지트 패턴" 이라고 어디가서 우기지나 않을까 염려된다.


이런 식 또한 많다. 무엇인가?? 당연히 알수가 없다.
또한 저런 동일한 구조에 여러 패턴이 같이 참여 할 수 도 있다. 예를들어 Strategy패턴과 Flyweight 패턴이 같은 클래스들을 공유하는 경우가 실제 세계에는 부지기수로 일어나기도 한다. 그럴 때는 A 클래스와 B 클래스는 OO 패턴 과 XX 패턴에 어떤 역할로 참여하고 있다 라고 말하며 회의시에 커뮤니케이션 할 수 있겠다. 

따라서 앞으로 나올 패턴 비교에서는 UML 에 대한 설명은 하지 않으며  그냥 말로 "의도" 를 전달 할 예정이다.
마지막으로 디자인패턴을 처음 공부하는 사람을 위한 글은 아니며, 대략 공부한 상태에서 정리하기 위한 목적의 글이라는 점을 양해 드린다. 



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

5. Facade vs Mediator 패턴 

6. Mediator vs Observer 패턴 

7. Bridge vs Abstract Factory 패턴 

8. Abstract Factory vs Factory Method 

9. Factory Method vs Templet Method 패턴 

10. Templet Method vs Builder 패턴 

11. Iterator vs Visitor 패턴 

12. Visitor vs Strategy 패턴 

13. Strategy  vs Chain of Responsibility 패턴 

14. Strategy vs State 패턴 

15. Flayweight vs Prototype 패턴

16. Prototype vs Memento 패턴 

17. Command vs Composite 패턴 



0 Comments
댓글쓰기 폼