From 39f3d6d212c0c934fec90088ea313af775dd5933 Mon Sep 17 00:00:00 2001 From: pewww Date: Tue, 13 Apr 2021 18:16:13 +0900 Subject: [PATCH 1/4] =?UTF-8?q?docs:=20=EA=B0=80=EA=B5=90(Bridge)=20?= =?UTF-8?q?=ED=8C=A8=ED=84=B4=20=EC=A0=95=EB=A6=AC=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- study/design-pattern/catalogs/bridge.md | 64 +++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 study/design-pattern/catalogs/bridge.md diff --git a/study/design-pattern/catalogs/bridge.md b/study/design-pattern/catalogs/bridge.md new file mode 100644 index 0000000..325568b --- /dev/null +++ b/study/design-pattern/catalogs/bridge.md @@ -0,0 +1,64 @@ +# 가교 (Bridge) + +a.k.a. 핸들/구현부(Handle/Body) + +가교 구현 형태 + +Abstraction: 기능(추상) - 구현을 가지고 있는 인터페이스를 멤버 변수를 가지며, 해당 멤버 변수를 통해 메서드를 호출한다! + +RefinedAbstraction: 재정의한 기능 + +Implementor: 구현 + +## 💡 책에서 설명하는 의도 + +"구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 합니다." + +## 🧐 우리 상황에 맞게 풀어 쓴 동기 + +하나의 추상적 개념이 여러 가지 구현으로 구체화될 수 있을 때, 대부분은 상속을 통해서 이 문제를 해결합니다.
+추상 클래스로 추상적 개념에 대한 인터페이스를 정의하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현합니다.
+그러나 이 방법만으로는 충분한 융퉁성을 얻을 수 없습니다.
+상속은 **구현과 추상적 개념을 영구적으로 종속**시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나 수정 및 확장하기가 쉽지 않습니다. + +## 🛠 활용성: 이럴 때 씁니다 + +- 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 +- 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때 +- 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때 + +## 🎁 결과 + +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) From ae39c74ba65243bd9e9575d6e61cfe638d3cb117 Mon Sep 17 00:00:00 2001 From: pewww Date: Tue, 13 Apr 2021 18:19:56 +0900 Subject: [PATCH 2/4] =?UTF-8?q?fix:=20=EA=B0=80=EA=B5=90=20=ED=8C=A8?= =?UTF-8?q?=ED=84=B4=20=EB=AC=B8=EC=84=9C=20=EB=82=B4=EC=9D=98=20=EC=9D=BC?= =?UTF-8?q?=EB=B6=80=20=EA=B0=84=EA=B2=A9=20=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- study/design-pattern/catalogs/bridge.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/study/design-pattern/catalogs/bridge.md b/study/design-pattern/catalogs/bridge.md index 325568b..19e3e78 100644 --- a/study/design-pattern/catalogs/bridge.md +++ b/study/design-pattern/catalogs/bridge.md @@ -16,15 +16,20 @@ Implementor: 구현 ## 🧐 우리 상황에 맞게 풀어 쓴 동기 -하나의 추상적 개념이 여러 가지 구현으로 구체화될 수 있을 때, 대부분은 상속을 통해서 이 문제를 해결합니다.
-추상 클래스로 추상적 개념에 대한 인터페이스를 정의하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현합니다.
-그러나 이 방법만으로는 충분한 융퉁성을 얻을 수 없습니다.
+하나의 추상적 개념이 여러 가지 구현으로 구체화될 수 있을 때, 대부분은 상속을 통해서 이 문제를 해결합니다. + +추상 클래스로 추상적 개념에 대한 인터페이스를 정의하고, 구체적인 서브클래스들에서 서로 다른 방식으로 이들 인터페이스를 구현합니다. + +그러나 이 방법만으로는 충분한 융퉁성을 얻을 수 없습니다. + 상속은 **구현과 추상적 개념을 영구적으로 종속**시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나 수정 및 확장하기가 쉽지 않습니다. ## 🛠 활용성: 이럴 때 씁니다 - 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 + - 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때 + - 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때 ## 🎁 결과 @@ -57,7 +62,7 @@ Implementor: 구현 모스 부호는 점(.), 대쉬(-), 스페이스( ) 로 나뉩니다. -따라서, A를 모스 부호로 나타낸다고 했을 때 점, 대쉬로 표현이 가능합니다. +따라서, A를 모스 부호로 나타낸다고 했을 때 점, 대쉬, 스페이스로 표현이 가능합니다. 그럼 A, B, C를 모스 부호로 표현하고자 할 때 어떻게 설계 할 수 있을까요? From 403715c2ec48fa33c4a283733f2cdd4279fbc7a0 Mon Sep 17 00:00:00 2001 From: pewww Date: Tue, 13 Apr 2021 18:20:55 +0900 Subject: [PATCH 3/4] =?UTF-8?q?fix:=20=EA=B0=80=EA=B5=90=20=ED=8C=A8?= =?UTF-8?q?=ED=84=B4=20=EC=98=88=EC=8B=9C=20=EB=A7=81=ED=81=AC=20=EB=AA=85?= =?UTF-8?q?=EC=B9=AD=20=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- study/design-pattern/catalogs/bridge.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/study/design-pattern/catalogs/bridge.md b/study/design-pattern/catalogs/bridge.md index 19e3e78..c942238 100644 --- a/study/design-pattern/catalogs/bridge.md +++ b/study/design-pattern/catalogs/bridge.md @@ -66,4 +66,4 @@ Implementor: 구현 그럼 A, B, C를 모스 부호로 표현하고자 할 때 어떻게 설계 할 수 있을까요? -확인: [https://github.com/Pewww/WIL/bridge_pattern](https://github.com/Pewww/WIL/tree/master/20210315) +확인: [Bridge Pattern Example](https://github.com/Pewww/WIL/tree/master/20210315) From bca9c04b5479f470dfd4934b429fcdec6b809cce Mon Sep 17 00:00:00 2001 From: Pewww Date: Mon, 8 Aug 2022 16:32:09 +0900 Subject: [PATCH 4/4] =?UTF-8?q?docs:=20Bridge=20=ED=8C=A8=ED=84=B4?= =?UTF-8?q?=EC=97=90=20=EB=8C=80=ED=95=9C=20=EC=84=A4=EB=AA=85=20=EB=B3=B4?= =?UTF-8?q?=EA=B0=95=20=EB=B0=8F=20=EC=98=88=EC=8B=9C=20=EB=A7=81=ED=81=AC?= =?UTF-8?q?=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- study/design-pattern/catalogs/bridge.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/study/design-pattern/catalogs/bridge.md b/study/design-pattern/catalogs/bridge.md index c942238..e7c8843 100644 --- a/study/design-pattern/catalogs/bridge.md +++ b/study/design-pattern/catalogs/bridge.md @@ -4,16 +4,20 @@ a.k.a. 핸들/구현부(Handle/Body) 가교 구현 형태 -Abstraction: 기능(추상) - 구현을 가지고 있는 인터페이스를 멤버 변수를 가지며, 해당 멤버 변수를 통해 메서드를 호출한다! +Abstraction: 기능(추상) - 추상적 개념에 대한 인터페이스를 제공하고 객체 구현자(Implementor)에 대한 참조자를 관리합니다. -RefinedAbstraction: 재정의한 기능 +RefinedAbstraction: 추상적 개념에 정의된 인터페이스를 확장합니다. + +Implementor: 구현 클래스에 대한 인터페이스를 제공합니다. + +ConcreteImplementor: Implementor 인터페이스의 구현체로 실제적인 구현 내용을 담습니다. -Implementor: 구현 ## 💡 책에서 설명하는 의도 "구현에서 추상을 분리하여, 이들이 독립적으로 다양성을 가질 수 있도록 합니다." + ## 🧐 우리 상황에 맞게 풀어 쓴 동기 하나의 추상적 개념이 여러 가지 구현으로 구체화될 수 있을 때, 대부분은 상속을 통해서 이 문제를 해결합니다. @@ -24,6 +28,7 @@ Implementor: 구현 상속은 **구현과 추상적 개념을 영구적으로 종속**시키기 때문에, 추상적 개념과 구현을 분리해서 재사용하거나 수정 및 확장하기가 쉽지 않습니다. + ## 🛠 활용성: 이럴 때 씁니다 - 추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 @@ -32,6 +37,7 @@ Implementor: 구현 - 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때 + ## 🎁 결과 1. 인터페이스와 구현 분리 @@ -45,6 +51,7 @@ Implementor: 구현 3. 구현 세부 사항을 사용자에게서 숨기기 - 상세한 구현 내용을 사용자에게서 은닉할 수 있습니다. + ## 🗺 구현 방법 1. Implementor 하나만 둡니다. @@ -56,14 +63,15 @@ Implementor: 구현 4. 다중 상속을 이용합니다. -## 🔙 우리가 사용한 예시 (또는 우리가 사용했다면) + +## 🔙 사용 예시 ![모스 부호 이미지](https://user-images.githubusercontent.com/23455736/114528175-b9653a80-9c83-11eb-8d62-9b5ea9d7454b.png) 모스 부호는 점(.), 대쉬(-), 스페이스( ) 로 나뉩니다. -따라서, A를 모스 부호로 나타낸다고 했을 때 점, 대쉬, 스페이스로 표현이 가능합니다. +따라서, A를 모스 부호로 나타낸다고 했을 때 점 + 스페이스 + 대쉬로 표현이 가능합니다. 그럼 A, B, C를 모스 부호로 표현하고자 할 때 어떻게 설계 할 수 있을까요? -확인: [Bridge Pattern Example](https://github.com/Pewww/WIL/tree/master/20210315) +[예시 확인하러 가기](https://codesandbox.io/s/meshkorea-fe-bridge-pattern-5uyfrc?file=/src/index.ts)