[디자인패턴] Bridge Pattern (브릿지 패턴)

• 브릿지 패턴의 목적과 사용이유
• 브릿지 패턴
• 다른패턴과의 비교

---

 

• 브릿지 패턴의 목적과 사용이유

Purpose

Object Structure에서 (Abstract)Conceptual 과 Implementation을 독립적으로 구분하여 coupling을 줄이기 위해서

Use When

Abstraction과 Implementation이 compile time에 바인딩되면 안될때

Abstraction과 Implementation이 독립적으로 확장 가능해야할때

Implementation에 대한 정보는 Client로부터 숨기고 abstraction에 영향가지 않도록 하고 싶을때

-> 결론적으로 Abstraction과 Implementation을 따로 분리하기 위해서!!

 

Initial Problem

문제

각각 Rectangle이 갖고있는 차이점은 어떤 방식으로 drawLine을 구현했냐이다.

Concrete인 V1, V2에서 drawLine을 구현하고있다. (각각 DP1, DP2에 의해서)

 

Requirement Changes

원도 생겼다. 따라서 Shape이라는 클래스를 더 상위에 놓아서 Rec, Cir이 같은 interface를 이용하게한다.

복잡도가 증가했다

문제 : Concrete Object에서 draw를 구현하고 있다.

이러면 shape종류가 늘어나던가 DP라이브러리(도구)가 늘어나면 Concrete class개수가 엄청 증가한다.

즉, abstract(shape종류) & implementation(구현방법=drawing program)에 따라 곱셈만큼 Concrete가 증가한다.

원인 : Shape과 DP가 tightly Coupled

해결 : 개념상에서의 variation(변종)와 구현상에서의 variation(변종)을 분리하자!

 

다른시도 : 상속이 hierarcht가 잘못된건가? 라이브러리를 세분화하고 shape을 세분화할까?

새로운 시도

DP에 대한 디펜던시 중복문제는 해결할 수 있지만 여전히 본질적인 문제는 고쳐지지 않았다. (클래스 개수 여전해..)

 

 

이때 각 Object가 똑같은 Shape에 대해서는 같은 interface 도구를 이용하여 그릴 수 있게 해야한다.

Client 보기에 Rectangle, Circle 모두 같은 interface(도구)를 이용할 수 있게 해야한다.

 

 

 

---

 

• 브릿지 패턴

위 문제를 해결하기 위해서는 두가지를 해야한다.

1. Commonality analysis (공통점 분석) -> Abstract class로

2. Variability analysis (변하는것 분석) -> Concrete class로

 

Commonality 분석

위 경우 서로다른 shape과 drawing 프로그램이 있다. 공통적인 concept은 Shape과 Drawing 프로그램이다.

Shape과 Drawing자체는 변하지 않으므로 abstract수준으로 만든다.

Common concepts

Variability 분석

Shape의 concrete와 Drawing프로그램의 concrete는 변할 수 있다. 따라서 concrete class로 만든다.

Variation 분석

 

Relating each other

두 클래스들을 한쪽이 다른 한쪽을 사용하도록 연관시켜야한다.

Option1 : Drawing 프로그램에서 Shape을 사용하도록

drawing에서 다양한 shape을 그려주려면 shape의 detail들을 다알아야해 (encapsulation 안좋아) 

(ex. rectangle을 위해서 drawline 4번 / 육각형은 drawline 6번 ... )

Option2 : Shape이 Drawing 프로그램을 사용하도록
shape이 drawing을 알도록하면 Drawing type몰라도돼

(ex. rectangle은 자신이 drawline 4번 필요한걸 알아 / ... )

 

두  abstract들을 encapsulate한다.
Inheritance대신 Composition을 사용한다.

개념에 해당하는놈들과 구현해당하는 놈들이 되게 독립적 (bridge) 
좌측변화 우측변화가 서로 독립적! 

 

 

 

---

 

• 브릿지 패턴

전략패턴 : 알고리즘계속 바뀔수잇어서 해당하는 behavior가 변종이나와서 그거에 바꿔치기하도록하려고
behavior중에도 공통 / 공통X잇는데 공통 X를 인캡슐하니까 전략패턴

전략패턴은 behavior를 각각 encapsulate시켜서 run-time때 behavior 고르도록

브릿지 : 개념 / 구현 즉, 구조적으로 encapsulate시킴

두 다이어그램같지만 문제시작점이 달라

어댑터랑도 유사!
-> 주어진 하위 인터페이스 던져주면서 detail은 숨겨
어댑터 : 디자인된 이후에 고치는 목적 (사후에 치료), 연관되지 않은 두 인터페이스를 연관짓는다.
브릿지 : 클래스 폭발현상, 디자인 단계에서 먼저 설계한다 (사전에 적용되는 패턴)

개념적인 정보와 구현관련 정보 이 둘을 분리시켜야 독립적으로 진행가능하다