- 인터페이스와 구현의 명확한 분리 문제 
 - 자세한 구현과 추상화라는 개념을 분리해서 표현
 - MFC의 Doc와 View의 분리 
 - 직렬화도 브리지 패턴의 한 예임

인터페이스 클래스와 구현 클래스의 독립 설계

인터페이스 클래스의 그것은 구현해주는 클래스들의 상속관계를 독립적으로 정의하고 이들간의 마치 다리를 연결하여 사용하는형태의 클래스 구조

클라이언트는 인터페이스 클래스만 참조. 구현 클래스 변경에 영향 받지 않음

Bridge 패턴의 유용성

인터페이스와 구현방식이 완전 결합되는 것을 피하고자 할 때
인터페이스와 구현 방식이 각각 서로 다른 형태의 하위 클래스 구조를 가지면서 확장되기를 원할 때
인터페이스의 구현 방식이 변경되더라도 그 인터페이스를 사용하는 Client 소스 코드는 다시 컴파일 하지 않아야 할 때
인터페이스의 구현 방식을 Client에게 완전히 숨기고 싶을 때
어떤 클래스의 상속 구조가 여러 개의 분류 기준에 의해 정의되어 복잡할 때
하나의 구현 객체를 여러 개의 인터페이스 객체가 공유하게 만들면서도 Client는 이를 알지 못하게 하고 싶을 때

Bridge 패턴의 장점

인터페이스와 구현을 분리.
실행 시간에 구현 객체를 바꾸거나 설정 할 수 있다구현 내용이 변경되더라도 인터페이스 클래스와 Client는 다시 컴파일 할 필요가 없다.
전반적인 설계가 좀더 계층화, 구조화될 수 있다.
Client 입장에서는 인터페이스와 어떤 객체로 구현이 이루어 지는지만 알면 된다.
인터페이스 클래스와 구현 클래스가 별도의 상속 구조를 가지므로, 서로 독립적으로 확장이 가능하다.
구현의 자세한 부분을 Client 에게 모두 숨길수 있다.

구현 관련 사항

구현 클래스의 상위에 추상 클래스(Abstract Base Class) 두는 것이 바람직
여러 구현 클래스 존재할 때 인터페이스 클래스가 어떤 것 사용할지를 언제, 어떻게 결정할까?
인터페이스 클래스의 생성자에서 결정: 인터페이스 클래스가 모든 구현 클래스를 알고있어야
처음에는 기본적인 구현 클래스 사용하다가 일정기준 넘어서면 동적으로 변경
인터페이스 클래스가 어떤 구현 클래스 쓸지 신경안쓰도록 별도의 객체에 위임 (예:AbstractFactroy 패턴, factory)

코드로 이해 하자!!

#include <iostream>
using namespace std;

// Bridge : 구현과 interface분리..

//1) 실제 구현 코드
class RealCar
{
public:
 void go() { cout << "go" << endl;  }
 void stop() { cout << "stop" << endl; }
};

// 2) interface 역할
class Car
{
 RealCar c;
 
public:
 void Go() { c.go(); }
 void Stop() { c.stop(); }
};

void main()
{
 Car c;
 
 c.Go();
}

참고 사이트 (http://ani2life.egloos.com/2904131)