GoF의 디자인 패턴 - Bridge

Structural Patterns(구조 패턴) :: Bridge(가교)

구분
 객체 구조 (Object Structural)

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

다른이름
 핸들/구현부(Handle/Body)

사용시기
 - 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때, 이를테면, 런타임에 구현 방법을 선택하거나 구현 내용을 변경하고 싶을 때
 - 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때, 이 때, 가교 패턴은 개발자가 구현을 또 다른 추상적 개념과 연결할 수 있게 할 뿐 아니라, 각각을 독립적으로 확장 가능하게 한다.
 - 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때, 즉, 추상적 개념에 해당하는 클래스를 사용하는 코드들은 구현 클래스가 변경되었다고 해서 다시 컴파일되지 않아야 한다.
 - 클래스의 구현과 속성에 대한 모든 표현 방식이 완전하게 은닉되도록 할 때
 - 클래스의 상속 계통에서 클래스 수가 급증하는 것을 방지하고자 할 때

 - 여러 객체들에 걸쳐 구현을 공유하고자 하며, 또 이런 사실을 사용자 쪽에 공개하고 싶지 않을 때

장점과 단점
 1. 인터페이스와 구현 분리
 2. 확장성 제고
 3. 구현 세부 사항을 사용자에게서 숨기기

구현의 유의점
 1. Implementor 하나만 둔다.
 2. 정확한 Implementor 객체를 생성한다.
 3. Implementor를 공유한다.
 4. 다중 상속을 이용한다. (진정한 의미의 Bridge패턴이 될 순 없다.)

관련 패턴
 Abstract Factory(추상 팩토리) 패턴을 이용해서 특정 Bridge(가교)를 생성하고 복합할 수 있도록 한다.
 Adaptor(적응자) 패턴은 서로 관련이 없는 클래스들이 함께 동작하게 만드는 쪽에 특화시켜 만든 패턴이다. 이 패턴은 대개 각 클래스의 설계가 끝난 후에 적용된다. 한편, Bridge(가교) 패턴은 설계 단계 초기에 투입되어 추상화 및 구현이 독립적으로 다양화되도록 만드는 데 쓰인다.



참조문헌
- GoF의 디자인패턴