5. Structural 패턴 - Bridge Pattern

문제 정의

간단하게 그림을 그릴 수 있는 프로그램을 만들고자 한다.

처음에는 사각형을 그리는 라이브러리가 두 종류(함수 DP1, DP2)가 존재한다.

 

처음에는 두 라이브러리 밖에 없지만 추가될 수 있으므로

변하지 않는 Rectangle을 만들고(client가 접근하는 부분) 변하는 부분(V1, V2...)을 concrete class로 구현하여 encapsulate한다.

drawline이 어떤 라이브러리로 사용할 지 rectangle class level에서 결정하지 못해서

abstract 함수로 구현하여 하위 class에서 Implementation할 수 있도록 한다.

여기서 사각형 뿐만 아니라 다양한 모양(ex. 원)을 그리는 방법을 추가하고자 한다.

모든 모양을 포용하고 나타낼 수 있는 class가 필요하다.

따라서 Rectangle, Circle의 상위 개념인 Shape이라는 class를 추가한다.

 

그런데, 모양이 더 추가되거나 라이브러리가 추가되었을 때를 생각해보자.

 

모양이 추가된다면, 추가된 모양의 개수 X 라이브러리 수 = 추가된 class 수

라이브러리가 추가(DP3)된다면, 모양의 개수 X 추가된 라이브러리 수 = 추가된 class 수

같이 곱셈으로 class수가 증가되어 과도하게 생성된다.

(V1Circle처럼 모양과 라이브러리가 한 class내에 구현 되어 있어 둘의 coupling이 너무 강하기 때문에 발생한다.)

 

번외로, 

Shape 아래 level을 라이브러리 level로 설정해도 똑같은 현상이 발생한다.

 

 

해결 방법

변하지 않는 Shape, Drawing은 abstract로 구현하고 변하는 모양, 라이브러리는 encapsulate 시킨다.

Client는 어떤 라이브러리를 사용할지 dp를 통해서 결정하고 모양의 parameter로 이용한다.

 

 

Bridge Pattern

Abstraction과 Implementation을 decoupling시켜서 Abstract나 Implementation의 확장이 서로 영향을 미치지 않도록 하는 패턴

 

Adapter Pattern vs. Bridge Pattern

공통점 : Structural Pattern으로 목적이 동일하다(Implementation의 detail을 감춰준다)

차이점

• Adapter Pattern : 설계 이후에 적용한다. (reengineering)
• Bridge Patten : 구조적인 문제가 생길 것 같아서 미리 적용하여 미리 대비한다.