[디자인패턴] bridge & adapter & mediator pattern

bridge pattern : 기능의 계층과 구현의 계층을 분리한다

'기능의 클래스 계층' 과 '구현의 클래스 계층' 사이에 다리를 놓는다.

클래스 계층의 두 가지 역할

• 새로운 '기능'을 추가하고 싶을 때

something

|

----- somethingGood

|

------- somethingBetter

새로운 기능을 추가하고 싶을 때 클래스 계층 안에서 새로 만들려고 하는 클래스와 유사한 클래스를

찾아내 하위 클래스를 만들어 기능을 추가

ps. 일반적으로 클래스 계층은 너무 깊게 하지 않는 것이 좋다

• 새로운 '구현'을 추가하고 싶을 때

AbstractClass

  |

  ------ ConcreateClass

|

-------- AnotherConcreateClass

두개로 클래스 계층을 나눠두면 각각의 클래스 계층을 독립적으로 확장할 수 있다

기능을 추가하고 싶으면 기능의 클래스 계층에 클래스를 추가한다

이때 구현의 클래스 계층은 전혀 수정하지 않아도 된다. 게다가 새로 추가한 기능은 '모든 구현'에서 이용 할 수 있다

상속은 견고한 연결, 위임은 느슨한 연결

장점  

구현을 인터페이스에 완전히 결합시키지 않았기 때문에 구현과 추상화된 부분을 분리시킬 수 있다.

추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있다

추상화된 부분을 구현한 구상 클래스를 바꿔도 클라이언트 쪽에는 영향을 끼치지 않는다

활용법 및 단점

추상과 구현이 한 클래스에 같이 붙어있지 않고 그들을 분리하여 확장을 쉽게 하고 싶을 때 사용한다.

그 결과 추상과 구현이 분리되어 결합도가 낮아진다.

추상은 그대로 두고 구현만 프로그램  실행중에 변경해도 다른 클라이언트에게 영향을 미치지 않게 할 경우에 적용한다.

그 결과 추상과 구현을 서로 독립적으로 확장할수 있어 확장성이 개선된다.

여러 플랫폼에서 사용해야 할 그래픽스 및 윈도우 처리 시스템에서 유용하게 쓰인다

인터페이스와 실제 구현부를 서로 다른 방식으로 변경해야 하는 경우에 유용하게 쓰인다

디자인이 복잡해진다는 단점

Adapter pattern   : 필요한 형태로 수정해서 재활용한다

 = Wrapper pattern

무언가를 싸서 다른 용도로 사용할 수 있도록 교환해 주는 것

•  클래스에 의한 Adapter pattern(상속을 이용)
•  인스턴스에 의한 Adapter pattern(위임을 이용)

Adapter pattern은 기존의 클래스를 수정해서 필요한 클래스로 만든다. 이 패턴에 의해

필요한 메소드를 재빨리 만들 수 있다. 만약 버그가 발생하더라도 기존의 클래스에는

버그가 없기 때문에 Adapter 역할의 클래스를 중점적으로 조사만 하면 되니깐 프로그램 체크가

아주 간편해진다

버전과 호환성

소프트웨어를 버전업할때 문제가 되는 것이 '기존 버전과의 호환성'이다

기존 버전을 버리면 소프트웨어의 보수는 간단하지만 항상 그것이 가능하다고는 할 수 없다

기존 버전과 새로운 버전을 공존시키고 보수를 간단하게 하는데 Adapter pattern이 도움이 되는 경우가 있다

예제)

구식 Enumeration과 신형 Iterator의 결합

public class EnumerationIterator implements Iterator

{

Enumeration enum;

public EnumerationIterator(Enumeration eunm){

this.enum = enum;

}

public boolean hasNext(){

return enum.hasMoreElements();

}

public Object next(){

return enum.nextElement();

}

public void remove(){

throw new UnsupportedOperationException();

}

}

Adapter pattern은 겉보기에 Bridge와 비슷해 보인다. 하지만 Adapter pattern은 어떤 클래스의 인터페이스가 다른 코드에서 기대하는 것과 다를때 어댑터를

중간에 두어서 맞춰주는 것이고, Bridge는 추상과 구현을 분리하는 것으로 그 의미가 명백히 구별된다.

 Mediator : 상대는 하나뿐

 mediator : 조정자, 중개자

다수의 객체를 조정해야 하는 경우에 사용

서로 관련된 객체 사이의 복잡한 통신과 제어를 한 곳으로 집중시키고자 하는 경우에 사용

서로 협력해야 하는 여러 객체들의 "중재자"가 존재하여 그들이 서로를 알지 못하더라도 다른 객체에 메시지를 보내고 받을 수 있다.

미디에이터를 사용하면,,

상태가 바뀔 때마다 미디에이터한테 알려주고, 미디에이터에서 보낸 요청에 응답을 한다

미디에이터를 추가하기 전에는 모든 객체들이 다른 객체들하고 서로 알고 있어야 했다

서로 밀접하게 연관되어 있었지만 미디에이터를 사용한 후로는 서로 완전히 분리될 수 있다.

미디에이터에는 모든 시스템을 제어할 수 있는 로직이 들어있다. 새로운 규칙을 추가해야 한다거나

새로운 시스템에 추가하더라도 미디에이터만 고치면 된다.

장점

시스템하고 각 객체를 분리시킴으로써 재사용성을 획기적으로 향상시킬 수 있다

제어 로직을 한 군데 모아놨기 때문에 관리하기가 수월하다

시스템에 들어있는 객체 사이에서 오가는 메시지의 종류를 확 줄이고 단순화시킬 수 있다

활용법 및 단점

서로 연관된 GUI 구성요소들을 관리하기 위한 용도로 많이 쓰인다

디자인을 잘 하지 못하면 미디에이터 객체 자체가 너무 복잡해 질 수 있다.

"중재자" 클래스에 모든 객체들에 대한 컨트롤이 집중되기 때문에 프로그램이 규모가 커질수록 이해하기 힘들어진다.

Facade 패턴과의 관계

Facade 패턴은 서브 시스템을 상징하는 클래스(Facade 클래스)를 통해 서브 시스템 내부의 클래스들의 존재를 모른 상태에서 그 기능을

사용하게 해준다. 서브 시스템내의 클래스는 Facade 클래스의 존재를 모른다. 하지만,

Mediator 패턴은 모든 협력 클래스들은 중재자(Mediator) 클래스의 존재를 알아야 한다.

/***************************************

***** Design Pattern 정리 - flyburi.com 버리  ****

*************************************************/