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의 디자인패턴

디자인패턴...유연성 편

디자인 패턴이 소프트웨어 구축에 줄 수 있는 유연성의 예

1. 특정 클래스에서 객체 생성
   : 객체를 생성할 때 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속된다. 이런 종속은 앞으로의 변화를 수용하지 못한다. 이를 방지하려면 객체를 직접 생성해서는 안된다.

   : 사용할 수 있는 디자인 패턴
     - Abstract Factory
     - Factory Method
     - Prototype


2. 특정 연산에 대한 의존성
   : 특정한 연산을 사용하면, 요청을 만족하는 한 가지 방법에만 매이게 된다. 요청의 처리 방법을 직접 코딩하는 방식을 피하면 컴파일 시점과 런타임 시점, 모두를 만족하면서 요청 처리 방법을 쉽게 변경할 수 있다.

   : 사용할 수 있는 디자인 패턴
     - Chain of Responsibility
     - Command


3. 하드웨어와 소프트웨어 플랫폼에 대한 의존성
   : Legacy시스템의 인터페이스는 플랫폼마다 다르다. 특정 플랫폼에 종속된 코드는 마이그레이션이 어렵다. 이러한 종속성을 제거하는 것이 중요하다.

   : 사용할 수 있는 디자인 패턴
     - Abstract Factory
     - Bridge


4. 객체의 표현이나 구현에 대한 의존성
   : A객체가 B객체의 표현 방법, 저장 방법, 구현 방법, 존재의 위치에 대한 모든 방법을 알고 있다면 B객체를 변경할 때 A객체도 함께 변경해야 한다. 이런 정보를 감춤으로써 변화의 파급을 막을 수 있다.

   : 사용할 수 있는 디자인 패턴
     - Abstract Factory
     - Bridge
     - Memento
     - Proxy


5. 알고리즘 의존성
   : 알고리즘에 종속된 객체가 있다면 변화에도 종속되게 되므로, 변경 가능한 알고리즘은 분리해야 한다.

   : 사용할 수 있는 디자인 패턴
     - Builder
     - Iterator
     - Strategy
     - Template Method
     - Visitor


6. 높은 결합도 (https://ko.wikipedia.org/wiki/%EA%B2%B0%ED%95%A9%EB%8F%84)
   : 높은 결합도를 갖는 클래스는 독립적으로 재사용하기 어렵다. 또한 하나의 커다란 시스템이 되어 버린다. 결국 전체를 이해하지 못하면 조그만 변경도 하기 어려워지며, 변경 시 종속된 다른 클래스들도 함께 변경되어야 한다. (유지보수 불가의 공룡 시스템)

     약한 결합도는 클래스를 재사용 가능하게 하고, 시스템의 이해와 수정, 확장이 쉬워진다. 추상 클래스 수준에서 결합도를 정의한다거나 계층화시키는 방법으로 낮은 결합도의 시스템을 만드는 것이 중요하다.

   : 사용할 수 있는 디자인 패턴
     - Abstract Factory
     - Bridge
     - Chain of Responsibility
     - Command
     - Facade
     - Mediator
     - Observer


7. 서브클래싱을 통한 기능 확장
   : 서브클래싱으로 객체를 재정의하는 것은 쉬운 일이 아니다. 새로운 클래스마다 매번 반드시 해야 하는 초기화, 소멸 등에 대한 구현 오버헤드가 있기 때문이다. 서브클래스를 정의하려면, 최상위 클래스부터 자신의 직속 부모 클래스까지 모든 것을 이해하고 있어야 한다. 또한, 단순히 확장만을 이유로 새로운 서브클래스를 만든다면 서브클래싱은 클래스의 수를 엄청나게 증가시킬 수도 있다. 일반적으로 객체 합성과 위임은 상속보다 훨씬 유연한 방법이다. 기존 객체들을 새로운 방식으로 조합함으로써 새로운 서브클래스를 정의하지 않고도 새로운 기능을 추가할 수 있다. 하지만 객체 합성을 많이 사용한 시스템은 이해하기가 어려워진다. 많은 디자인 패턴에서는 그냥 서브클래스를 정의하고 다른 인스턴스와 새로 정의한 클래스의 인스턴스를 합성해서 기능을 재성의하는 방법을 도입한다.

   : 사용할 수 있는 디자인 패턴
     - Bridge
     - Chain of Responsibility
     - Decorator
     - Strategy


8. 클래스 변경이 쉽지 않은 경우
   : 변경을 할 경우 종속된 서브클래스들을 모두 수정해야 하는 경우 클래스를 수정하는 방법을 디자인 패턴이 제시한다.

   : 사용할 수 있는 디자인 패턴
     - Adapter
     - Decorator
     - Visitor

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