Bridge
Structural Pattern
거대한 클래스 또는 밀접한 관련이 있는 클래스들의 집합을 두 개의 계층 구조(추상화-구현)로 나눈 후 독립적으로 개발할 수 있는 구조 디자인 패턴
문제
모양과 색상이 있을 때 빨간색, 파란색이라는 색상이라는 도입하려고 하면 빨간색 사각형, 빨간색 원, 파란색 사각형, 파란색 원 이렇게 네 가지 클래스 조합이 필요합니다.
이런 식이라면 새로운 도형과 새로운 색상을 추가하려면 기하 급수적으로 클래스가 증가하게 됩니다.
해결책
이러한 문제는 모양과 색상이라는 독립적인 차원에서 모양 클래스를 확장하려 했기 때문에 발생합니다.
Bridge 패턴 - 상속을 하지 않고 객체 합성을 통해 해결
하나의 차원을 별도의 클래스 계층으로 추출하여 한 클래스가 상태와 동작을 모두 가지는 대신 새로운 계층의 클래스를 참조하는 프로퍼티를 갖게 합니다. 이러한 참조가 두 클래스들 사이의 다리(브리지) 역할을 하게 됩니다.
위 예시에서는 색상이라는 자체를 클래스로 추출하여 분리할 수 있습니다. 그러면 모양이라는 객체는 색상과 관련된 모든 작업을 색상 객체에게 위임할 수 있습니다. 이제 색상 또는 모양을 추가할 때 서로의 계층을 변경할 필요가 없습니다.
추상화와 구현
추상화는 객체들의 상위 레이어로 실제 작업을 수행하지 않고 구현 계층에 위임합니다.
추상화 ➡️ 추상 클래스? 인터페이스? ❌
실제 앱을 예로 들자면 다음과 같습니다.
- 추상화 -> 그래픽 사용자 인터페이스(GUI)
- 구현 -> 그래픽 사용자 인터페이스와 사용자가 상호작용한 결과를 호출하는 API
이런 앱의 경우 확장할 때 두 가지 독립적인 방향을 가지게 됩니다.
1. 다른 여러 GUI를 가진다 (ex. 일반 고객용, 관리자용)
2. 다른 여러 API를 지원한다 (ex. 리눅스용, 윈도우용)
만약 브리지 패턴을 사용하지 않을 경우 어떤 GUI와 어떤 API인지를 연결할지에 따라 수백 개의 조건문이 코드 전체에 스파게티 코드처럼 형성될 수 있습니다.
특정 GUI와 API를 조합한 코드를 별도의 클래스로 추출하여 질서를 부여할 순 있지만 이러한 클래스들은 GUI와 API를 추가할 때마다 기하급수적으로 증가합니다.
브리지 패턴은 이 문제를 두개의 계층구조로 분리하여 해결합니다!
추상화 객체는 앱의 드러나는 모습을 제어하고 실제 작업은 연결된 구현 객체에 위임합니다. 서로 다른 구현들은 공통 인터페이스를 따르면 상호 호환이 가능하고, 이에 따라 같은 GUI 사용자는 리눅스와 윈도우 모두에서 작동할 수 있습니다.
API 관련 클래스를 건드리지 않고 GUI 클래스들을 변경할 수 있습니다. 또한 다른 API를 추가하려면 구현 계층구조에 자식 클래스를 생성하기만 하면 됩니다.
구조
- 추상화
- 상위 수준의 제어 논리를 제공
- 구현 객체의 의존
- 구현
- 모든 구현들에 대한 공통 인터페이스 선언
- 추상화는 인터페이스에 선언된 메서드를 통해서 구현 객체와 소통
- 구상 구현
- 인터페이스를 실제 코드로 구현
- 정제된(Refined) 추상화(❓)
- 선택 사항
- 제어 논리의 변형을 제공
- 클라이언트
- 일반적으로 추상화와 작업에만 관심
- 추상화 객체를 구현 객체 중 하나와 연결
적용
- 어떤 기능의 여러 변형을 가진 클래스를 나누고 정돈하려 할 때
- 여러 독립적인 차원에서 클래스를 확장해야 할 때
- 런타임에 구현을 전환할 수 있어야 할 때
장단점
✅ 장점
- 플랫폼 독립적인 클래스들을 만들 수 있다
- 클라이언트는 상위 수준의 추상화만 알고 플랫폼 세부 정보는 노출되지 않는다
- OCP원칙 준수 -> 새로운 추상화와 구현을 독립적으로 도입 가능
- SRP원칙 준수 -> 추상화의 상위 논리와 구현의 플랫폼 세부 정보를 분리
❎ 단점
- 결합도가 높은 클래스에 패턴을 적용할 경우 코드가 더 복잡해질 수 있음
참고링크
Bridge
