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 패턴을 이용하면 두 가지를 별도의 클래스 계층 구조에 배치하여 구현과 추상화를 다양화할 수 있다.
즉, 구체적인 클래스들 간의 의존성을 배제시킬 수 있다.
위 클래스 다이어그램에서 보는 바와 같이 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 |