-
Notifications
You must be signed in to change notification settings - Fork 22
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
64 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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) |