Use the Bridge Pattern to vary not only your implementations, but also your abstractions.

 

브리지 패턴은 추상층을 분리하여 각자 독립적으로 변형 및 확장이 가능하도록 만드는 패턴이다.

즉, 기능과 구현에 대해 두 개의 별도의 클래스로 구현한다.

 

예를 들어 TV 리모컨용 코드를 작성한다고 하자. 일단 각 리모컨으로 할 수 있는 여러가지 기능들이 있다.

이 기능들 중에 RCAControl, SonyControl이라는 두가지 기능이 있다고 해보자. 그런데 이 리모컨을 사용하는 여러가지 TV 모델들(LG, Samsung)도 있을 수 있다.

 

 

 

단순하게 생각했을 때, 왼쪽과 같이 리모컨이라는 동일한 추상화를 기반으로 TV의 각 모델마다 서로 다른 기능을 구현해 볼 수 있을 것이다.

 

하지만, 문제는 리모컨의 기능과 TV 모델들이 바뀔 수 있다는 점이다. 여러 TV에서 구현을 다양화할 수 있도록 리모컨은 이미 추상화했지만, 리모컨의 기능이 개선될때마다 TV 모델들의 구현 또한 변경되어야 할 수 있다.

 

뿐만 아니라, 리모컨의 기능이 추가된다면 해당 리모컨 기능에 대한 구현을 해야 한다.

 

 

 

 

 

 

 

 

 

 

 

이러한 경우에 Bridge 패턴을 이용하면 두 가지를 별도의 클래스 계층 구조에 배치하여 구현과 추상화를 다양화할 수 있다.

즉, 구체적인 클래스들 간의 의존성을 배제시킬 수 있다.

 

HeadFirst Design Pattern - Bridge Pattern

위 클래스 다이어그램에서 보는 바와 같이 RemoteControl과 TV는 각각 인터페이스이다.

그리고 구체적인 의존 관계는 이 인터페이스들 간에만 존재하기 때문에 이렇게 브리지를 사용하면 두 계층 구조의 양쪽을 독립적으로 변경할 수 있다.

 

이를 코드로 구현해보면 아래와 같다.

.

 

장점

  • 인터페이스에 (의존하지 않도록) 구현을 분리한다.
  • 추상화와 구현은 독립적으로 확장 될 수 있다.
  • 구체적인 추상화 클래스에 대한 변경 사항은 클라이언트에 영향을주지 않는다.

단점

  • 복잡성이 증가한다.

언제 사용하는가?

  • 여러 플랫폼에서 실행해야하는 그래픽 및 윈도우 시스템에 유용하다.
  • 다른 방식으로 인터페이스와 구현을 변경해야 할 때 유용하다.

 



'책을 읽자 > Design Patterns' 카테고리의 다른 글

Proxy pattern  (0) 2021.08.18
Decorator Pattern  (0) 2021.08.18
Template Method Pattern  (0) 2021.08.02
Strategy Pattern  (0) 2021.08.02
Flyweight Pattern  (0) 2021.01.19

+ Recent posts