하마
7k
2017-07-07 16:43:24 작성 2017-07-12 16:20:04 수정됨
3
4566

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


경어가 아닌점 양해 바랍니다. (_._) 



  
           꼬리에 꼬리를 무는  - 유사 디자인 패턴들 (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. Adapter vs Facade 패턴 

4. Facade vs Bridge 패턴 

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 패턴 




12
11
  • 댓글 3

  • fender
    24k
    2017-07-07 17:18:44 작성 2017-07-07 17:19:05 수정됨

    공감 가는 좋은 글 잘 읽었습니다. 저 역시 디자인 패턴을 배울 때는 UML 같은 표기법이나 구조를 암기하는 데 집착하면 안된다고 생각합니다.

    디자인 패턴의 정의는 흔히 접하는 문제들에 대한 해법을 모아놓은 것이고, 그렇다면 무턱대고 해법을 외우는 것보단 각 패턴이 요구되는 문제 상황을 정확하게 이해하고 눈에 익혀 두는 것이 더 중요한 문제가 아닌가 싶습니다.

    사실 '프록시'나 '데코레이터' 같은 용어는 의도를 나타내는 단어이지 반드시 특정 클래스의 구조를 지칭하는 이름은 아니라고 생각합니다. 단지 GoF 패턴에서 그런 개념을 특정 구조로 구현했을 뿐, 어느 구성 요소가 다른 요소를 '대리'하거나 '부연'한다는 개념 자체는 훨씬 일반적인 문제이니 말입니다.

    표기법이나 용어, 또는 특정 구조에 교조적으로 집착을 한다면 아마 디자인 패턴을 물어보는 면접 같은 건 잘 볼 수 있을 지 몰라도 실제 코드에 그런 내용을 적용해야 할 때는 오히려 어려움을 겪을 수 있는 것 같습니다.

    UML이 중요하다면 예컨대 이런 글을 보고 전달하려는 바가 무엇인지 이해할 수 있기 위함이고, 구조가 중요하다면 예컨대 어떤 문제를 풀기 위해 무언가 데코레이터 역할을 하는 클래스가 필요하다는 것을 깨달은 뒤 그것을 GoF의 데코레이터 패턴을 적용할 것이냐 AOP를 동원해서 풀 것이냐 등을 결정하는데 힌트를 얻기 위함이 아닌가 싶습니다.

    아직 디자인 패턴에 익숙하지 않은 분들이 이 글을 읽는다면, 무엇보다 중요한 건 표기법이나 구조가 아니라 실제 어떤 상황에서 왜 그런 접근 방법이 도움이 될 수 있는지 의도와 맥락을 이해하는 것임을 고민해보셨으면 좋겠습니다.

  • fender
    24k
    2017-07-07 17:39:31

    말씀처럼 패턴의 구분이 중요한 것은 아니지만, 검색을 하다 문제와 관련한 흥미로운 내용이 있어서 소개합니다:

  • 실력과연봉은비례하는가
    516
    2017-07-18 22:39:55

    비슷비슷해 보이는 디자인 패턴이 많아서 혼동스러운 점이 많았는데 덕분에 잘 정리하고 갑니다...17편 완결까지 쭉 기다리겠습니다~!

  • 로그인을 하시면 댓글을 등록할 수 있습니다.