본문 바로가기

Design Pattern

[Design pattern] Bridge

패턴

: 가교(Bridge)

의도

: 구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 한다.

다른 이름

: 핸들/구현부(Handle/Body)

동기

: 하나의 추상적 개념이 여러가지 구현으로 구체화될 수 있을때, 대부분은 상속을

통해서 이 문제를 해결한다. 추상 클래스로 추상적 개념에 대한 인터페이스를 정의

하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현 한다.

그러나, 이런 방법으로는 충분한 융통성을 가질 수 없다. 상속은 구현과 추상적

개념을 영구적으로 종속시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나

수정, 확장하기가 쉽지 않다.

활용성

:1. 런타임에 구현 방법을 선택하거나 구현 내용을 변경하고 싶을 때.

:2. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때.

가교 패턴은 구현을 또 다른 추상적 개념과 연결할 수 있게 할 뿐 아니라,

각각을 독립적으로 확장 가능하게 한다.

:3. 추상적 개념에 해당하는 클래스를 사용하는 코드들은 구현 클래스가 변경되었

다고 해서 다시 컴파일되지 않아야 한다. ㅂ :4. 구현을 완벽하게 은닉을 원할때.

:5. 클래스 계통에서 클래스의 수가 급증하는 것을 방지하고자 할 때.

:6. 여러 객체들에 걸쳐 구현을 공유하고자 하며, 도 이런 사실을 사용자 쪽에

공개하고 싶지 않을 때.

구조


결과

1. 인터페이스와 구현 분리

2. 확장성 제고

3. 구현 세부 사항을 사용자에게서 숨기기.

예제 코드

- 다음은 윈도우 인터페이스 객체이다. 인퍼페이스 객체는 구현 객체의 인스터에 대한

참조자를 관리한다.

- 다음은 구현 객체이다.

- Window를 상속하여 새로운 서브 클래스를 정의함으로써, 다른 종류의

윈도우를 정의할 수 있다. 이렇게 정의된 새로운 서브 클래스에는 추가적인

서비스를 제공하는 연산이 추가 될 수 있다.


- 여기서도 WindowImp에 대한 참조자를 이용하여 구체적인 구현을 얻어 자신의

서비스를 만들어 내고 있다.

- Window 연산들은 WindowImp 인터페이스에 따라서 이를 이용하여 구현하는데,

Window에 정의된 서비스 개념의 DrawRect는 두개의 Point매개변수에서 네개의

좌표를 구할 수 있다. 후에 WindowImp에 정의된 DeviceRect란 이름의 구현

개념의 연산을 호출하여 윈도우에 사각형을 그린다.


- WindowImp를 상속받는 서브클래스들을 이용하여 서로 다른 윈도우 시스템을

지원 할 수 있게 하는데 XWindowImp는 X 윈도우 시스템을 지원한다.

- PMWindowImp는 IBM 계열의 시스템을 지원한다.

- 이 서브 클래스들은 윈도우 시스템의 기본 기능들을 이용하여 WindowImp의

연산을 구현한다. 예를 들어, DeviceRect는 X 윈도우 시스템에서 아래와 같이

구현할 수 있다.

- PM 구현는 다음과 같다.

- 윈도우 객체는 어떤 방법으로 올바른 WindowImp서브 클래스를 얻을 수 있을까?

여기서는 Window가 이것을 책임지는 것으로 가정한다. 즉, GetWindowImp 연산을

통해서 원하는 WindowImp의 인스턴스를 얻게 된다.

'Design Pattern' 카테고리의 다른 글

[Design pattern] 복합체 Composite  (0) 2013.02.25
[Design pattern] 감시자 Observer  (0) 2013.02.25
[Design pattern] Reflection  (0) 2013.02.21
[Design pattern] Micro Kernel  (0) 2013.02.21
[Design pattern] PAC  (0) 2013.02.21