Bridge Pattern

브리지(가교) 패턴은 추상과 구현을 분리하여 각각이 독립적으로 확장될 수 있도록 하는 패턴이다.

 

 

들어가기 앞서, 확실히 해야할 것이 있다. 우리는 "상속"을 할때 보통 2가지 이유로 사용한다.

 

1. 추상적 개념 구현

추상의 구현

이건 용어적으로 JAVA에는 해당하지 않을 수 있다. (interface, implements 키워드가 따로 있기 때문)

어쨌든 그림과 같이 추상적 개념(기능)을 여러 형태로 구현하기 위해 "상속"시킨다.

 

2. 기능 확장

기능 확장

기존 클래스를 활용 및 확장하여 새로운 기능을 사용자에게 제공하기 위해 상속시킨다.

---

1번 2번 둘다 상속을 이용하지만 1번의 경우 서브 클래스에 특화된 기능을 추가하기 어렵다.

client는 FileSystem으로만 추상적 기능을 이용하기 때문이다.

반대로 2번은 client는 서브 클래스인 TV class만 사용하기 때문에 마음껏 확장 가능하다.

1번과 2번의 차이를 알면 브리지 패턴의 필요성을 잘 알게 된다.

---

여러분은 게임내 다양한 요소들을 하나의 추상적 개념으로 핸들링 하기 위해 다음과 같은 class를 정의하였다.

그리고나서, 한번 배치되면 움직이지 않는 StaticObject와 물리 엔진에 따라 움직이고,

충돌하는 등의 움직일 수 있는 DynamicObject로 두 형태로 구현하였다.

이때 사용자 입력에 따라 조작이 되는 Object 즉, UI 기능을 하는 Object의 추가 요구사항이 발생하였다.

그래서 UIObject를 추가하였다.

근데 생각해보면, UIObject는 확장 기능이다.

StaticObject가 조작될 수 있고, DynamicObject가 조작될 수 있다.

StaticObject도 DynamicObject도 UIObject가 될 수 있어야 한다.

죽음의 다이아몬드 2개~

이렇게 되니 죽음의 다이아몬드가 된다... UIStaticObject와 UIDynamicObject는 하는 수 없이

StaticObject, DynamicObject를 상속받지 않고 중복 구현하여 피할 수 있긴 하지만 여전히 구리다.

그래서 다음과 같이 변경하였다.

이런 구조를 가지면 좀더 깔끔하게 해결되지만, 문제는 이제 StaticObject와 DynamicObject는

UIObject에 강한 의존을 가지게 되었다... UI기능을 하지 않아도 상속하고 있으니 실제

코드에서 처리가 복잡해질 것이다.

 

앞서 얘기한 추상부 구현과 기능 확장이 상속으로만 해결하려 하여 이러한 문제가 발생하였다.

브리지 패턴은 이것을 분리해주는 패턴이다!

브리지 패턴을 적용하여 재설계된 모습

추상 기능부와 구현부를 분리하여 GameObject와 GameObjectImpl로 나누었다.

UIObject는 GameObject에 UI 조작기능을 확장한 것으로 GameObject를 확장시켰고,

StaticObject와 DynmiacObject는 GameObject 기능의 구체적 구현이므로 GameObjectImpl를 구현하고 있다.

이제 UI 조작이 필요한 GameObject를 다룰때 사용자는 UIObject를 인스턴스화하고,

필드에 있는 _impl를 통하여 StaticObject나 DynamicObject를 GameObjectImpl을 통하여 조작하면 된다.

추상과 구현이 분리되어 있어서 각각 따로 확장할 수 있게 되었다!

---

브릿지 패턴의 이러한 유연한 구조에도 불구하고 역시 단점은 있다. 

1. 기본적으로 코드 복잡성을 늘린다.

2. 기능 클래스를 통해야 하는 추가 오버헤드