docs: 가교(Bridge) 패턴 정리 추가

study/design-pattern/catalogs/bridge.md

@@ -0,0 +1,64 @@
+# 가교 (Bridge)
+
+a.k.a. 핸들/구현부(Handle/Body)
+
+<img src="https://user-images.githubusercontent.com/23455736/114527953-81f68e00-9c83-11eb-83d5-6db5eafd4187.png" width="800" alt="가교 구현 형태">
+
+Abstraction: 기능(추상) - 구현을 가지고 있는 인터페이스를 멤버 변수를 가지며, 해당 멤버 변수를 통해 메서드를 호출한다!
+
+RefinedAbstraction: 재정의한 기능
+
+Implementor: 구현
+
+## 💡 책에서 설명하는 의도
+
+"구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 합니다."
+
+## 🧐 우리 상황에 맞게 풀어 쓴 동기
+
+하나의 추상적 개념이 여러 가지 구현으로 구체화될 수 있을 때, 대부분은 상속을 통해서 이 문제를 해결합니다.<br>
+추상 클래스로 추상적 개념에 대한 인터페이스를 정의하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현합니다.<br>
+그러나 이 방법만으로는 충분한 융퉁성을 얻을 수 없습니다.<br>
+상속은 **구현과 추상적 개념을 영구적으로 종속**시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나 수정 및 확장하기가 쉽지 않습니다.
+
+## 🛠 활용성: 이럴 때 씁니다
+
+- 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때
+- 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때
+- 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때
+
+## 🎁 결과
+
+1. 인터페이스와 구현 분리
+    - 구현이 인터페이스에 얽매이지 않게 됩니다.
+    - 추상적 개념에 대한 어떤 방식의 구현을 택할지가 런타임에 결정될 수 있습니다.
+    - 이는 런타임에 어떤 객체가 자신의 구현을 수시로 변경할 수 있음을 의미합니다.
+
+2. 확장성 제고
+    - Abstraction과 Implementor를 독립적으로 확장할 수 있습니다.
+
+3. 구현 세부 사항을 사용자에게서 숨기기
+    - 상세한 구현 내용을 사용자에게서 은닉할 수 있습니다.
+
+## 🗺 구현 방법
+
+1. Implementor 하나만 둡니다.
+    - 구현 방법이 오로지 하나일 때 Implementor를 추상 클래스로 정의하는 것은 불필요합니다.
+
+2. 정확한 Implementor 객체를 생성합니다.
+
+3. Implementor를 공유합니다.
+
+4. 다중 상속을 이용합니다.
+
+## 🔙 우리가 사용한 예시 (또는 우리가 사용했다면)
+
+![모스 부호 이미지](https://user-images.githubusercontent.com/23455736/114528175-b9653a80-9c83-11eb-8d62-9b5ea9d7454b.png)
+
+모스 부호는 점(.), 대쉬(-), 스페이스( ) 로 나뉩니다.
+
+따라서, A를 모스 부호로 나타낸다고 했을 때 점, 대쉬로 표현이 가능합니다.
+
+그럼 A, B, C를 모스 부호로 표현하고자 할 때 어떻게 설계 할 수 있을까요?
+
+확인: [https://github.com/Pewww/WIL/bridge_pattern](https://github.com/Pewww/WIL/tree/master/20210315)