패턴
: 가교(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 |