Bridge Pattern 브릿지 패턴이란

Bridge Pattern 브릿지 패턴이란

 

Intent

Bridge 는 큰 클래스 또는 밀접하게 관련된 클래스 집합을 서로 독립적으로 개발할 수 있는 두 개의 개별 계층 구조(추출 및 구현)로 분할할 수 있는 구조 설계 패턴입니다.

 

Problem

Circle과 Square라는 Subclasses 쌍이 있는 Shape 클래스가 있다고 가정합시다. 이 클래스 계층을 확장하여 색상을 통합하려고 하므로 Red 및 Blue shape subclasses를 만들 계획입니다. 그러나 이미 두 개의 하위 클래스가 있으므로 BlueCircle 및 RedSquare와 같은 네 개의 클래스 조합을 생성해야 합니다.

계층(hierachy)에 새 형상 유형과 색상을 추가하면 계층 구조가 기하급수적으로 증가합니다. 예를 들어, 삼각형 모양을 추가하려면 두 개의 하위 클래스(각 색마다 하나씩)를 도입해야 합니다. 그런 다음 색상을 추가하면 각 모양에 대해 하나씩 세 개의 하위 클래스를 만들어야 합니다. 우리가 더 멀리 갈수록, 그것은 더 복잡해집니다.

 

 

Solution

이 문제는 Form (circle, square)과 Color (red, blue)의 두 가지 독립적인 차원으로 형상 클래스를 확장하려고 하기 때문에 발생한다. 그것은 class inheritance의 아주 흔한 문제이다.

Bridge Pattern은 inheritance에서 개체 구성으로 전환하여 이 문제를 해결하려고 합니다. 즉, 차원 중 하나를 별도의 클래스 계층 구조로 추출하여 원래 클래스가 하나의 클래스 내에 모든 상태와 동작을 포함하는 대신 새 계층의 개체를 참조하도록 합니다.

 

이 접근법에 따라, 우리는 두 개의 하위 클래스로 Color 관련 코드를 자체 클래스 (own class)로 추출할 수 있다: Red and Blue. 그런 다음 Shape 클래스는 색상 개체 중 하나를 가리키는 참조 필드를 가져옵니다. 이제 Shape는 연결된 색상 객체에 모든 색상 관련 작업을 위임할 수 있습니다. 이 참조 (reference)는 Shape 클래스와 Color 클래스 사이의 Bridge 역할을 합니다. 이제부터, 새로운 색을 추가하는 것은 shape hierarchy을 변경할 필요가 없고, 그 반대도 마찬가지이다.

 

 

Abstraction and Implementation

Abstraction (interface라고도 함)는 일부 엔터티를 위한 high-level control layer이다. 이 layer은 혼자서 어떤 실제 작업도 할 수 없게 되어 있습니다. 그것은 작업을 Implementation 계층에 위임해야 한다.

프로그래밍 언어의 interfaces 나 abstract classes에 대해서는 언급하지 않습니다. 이건 같은 게 아니에요.

실제 애플리케이션에 대해 이야기할 때 abstraction는 그래픽 사용자 인터페이스(GUI)로 나타낼 수 있으며 Implementation은 사용자 상호 작용에 대응하여 GUI 계층이 호출하는 기본 운영 체제 코드(API)일 수 있다.

일반적으로 이러한 앱을 두 가지 독립적인 방향으로 확장할 수 있습니다.
- 여러 가지 GUI(예: 일반 고객 또는 관리자용으로 맞춤)를 사용합니다.
- 여러 가지 API(예: Windows, Linux 및 MacOS에서 앱을 실행할 수 있음)를 지원합니다.

 

최악의 경우, 이 앱은 거대한 스파게티 그릇처럼 보일 수 있는데, 수백 개의 조건들이 다양한 종류의 GUI를 코드 전체에 걸쳐 연결하는 것이다.

 

특정 인터페이스 플랫폼 조합과 관련된 코드를 개별 클래스로 추출하여 이 혼돈의 질서를 가져올 수 있습니다. 하지만 곧 여러분은 이러한 수업이 많다는 것을 알게 될 것입니다. 새로운 GUI를 추가하거나 다른 API를 지원하려면 점점 더 많은 클래스를 만들어야 하기 때문에 클래스 계층 구조는 기하급수적으로 증가할 것입니다.

Bridge Pattern으로 이 문제를 해결해 봅시다. 클래스를 두 계층으로 나눌 것을 제안합니다.

Abstraction: 앱의 GUI 계층입니다.
Implementation: 운영 체제의 API.

Abstraction object는 연결된 Implementation 개체로 실제 작업을 위임하여 앱의 모양을 제어합니다. 공통 인터페이스를 따르는 한 서로 다른 Implementation이 상호 호환되므로 동일한 GUI가 Windows와 Linux에서 작동할 수 있습니다.

따라서 API 관련 클래스를 건드리지 않고 GUI 클래스를 변경할 수 있습니다. 또한 다른 운영 체제에 대한 지원을 추가하려면 Implementation 계층에서 subclass만 만들면 됩니다.

 

 

Structure

1. Abstraction는 높은 수준의 제어 논리를 제공합니다. 실제 낮은 수준의 작업을 수행하기 위해 Imlementation object에 의존합니다.

2. Implementation은 모든 구체적인 구현에 공통적인 인터페이스를 선언합니다. Abstraction는 여기서 선언된 메서드를 통해서만 Imlementation 개체와 통신할 수 있습니다.

Abstraction는 Imlementation과 동일한 방법을 나열할 수 있지만, 대개 Abstraction는 Imlementation에 의해 선언된 다양한 원시 연산에 의존하는 일부 복잡한 동작을 선언한다.

3. 구체적인 Imlementation에는 플랫폼별 코드가 포함되어 있습니다.

4. 정제된 Abstraction는 제어 논리의 변형을 제공한다. 부모처럼, 그들은 일반 구현 인터페이스를 통해 서로 다른 Imlementation으로 작업한다.

5. 일반적으로 클라이언트는 Abstraction 작업에만 관심이 있습니다. 그러나 Abstraction object를 Imlementation object 중 하나와 연결하는 것은 클라이언트의 작업입니다.

 

 

Applicability

1. Bridge Pattern을 사용하여 일부 기능의 여러 변형을 가진 단일 클래스를 분할하고 구성하려는 경우(예: 클래스가 다양한 데이터베이스 서버와 함께 작동할 수 있는 경우) Bridge Pattern을 사용합니다.

2. 클래스를 여러 orthogonal 직각 (독립) 차원으로 확장해야 하는 경우 패턴을 사용합니다.

 

3. 런타임에 구현을 전환해야 하는 경우 Bridge를 사용하십시오.

 

 

 

Pros and Cons

Pros

플랫폼에 독립적인 클래스 및 앱을 만들 수 있습니다.

클라이언트 코드는 높은 수준의 Abstraction와 함께 작동합니다. 즉, 플랫폼 세부사항이 노출되지 않습니다.

Open/Closed Principle. 개방/폐쇄 원칙. 새로운 추상화 및 구현을 서로 독립적으로 도입할 수 있습니다.

Single Responsibility Principle. 단일 책임 원칙. 추상화에서 높은 수준의 논리와 구현에서 플랫폼 세부 정보에 집중할 수 있습니다.

 

Cons

이 패턴을 매우 응집력이 높은 클래스에 적용함으로써 코드를 더 복잡하게 만들 수 있습니다.