Docs: 박승훈 7장-3

챕터_7/박승훈.md

@@ -838,4 +838,171 @@ console.log(decoratedMacBook.getPrice()); // 945
 
 ### 나의 생각
 
-위에서 언급되었던 그냥 decorator 패턴보다는 제 의문을 해결하는 방식인 것 같아요. 잘 이해해서 실무에 활용해보면 좋을 것 같아요.
+위에서 언급되었던 그냥 decorator 패턴보다는 제 의문을 해결하는 방식인 것 같아요. 잘 이해해서 실무에 활용해보면 좋을 것 같아요.
+
+
+
+## 행위 패턴
+
+> 객체 간의 의사소통을 돕는 패턴
+
+- 시스템 내 서로 다른 객체 간의 의사소통 방식을 개선하고 간소화하는 것이 목적
+- 관찰자, 중재자, 커맨드 패턴이 있다.
+
+
+## 관찰자 패턴
+
+> 한 객체가 변경될 때 다른 객체들에 변경되었음을 알릴 수 있게 해주는 패턴
+
+- 한 객체(주체)를 관찰하는 여러 객체들(관찰자)이 존재
+- 주체의 상태가 변화하면 관찰자들에게 자동으로 알림 전송
+
+
+### 관찰자 패턴의 구성요소
+
+- 주체(Subject): 관찰자 리스트를 관리하고, 추가 삭제 가능케 한다.
+- 관찰자(Observer): 주체의 상태 변화를 감지하는 update 인터페이스 제공
+- 구체적 주체(ConcreteSubject)
+  - 상태변화에 대한 알림을 모든 관찰자에게 전달
+  - 구체적 관찰자의 상태 저장
+- 구체적 관찰자(ConcreteObserver)
+  - 구체적 주체의 참조 저장
+  - 관찰자의 update 인터페이스를 구현
+  - 주체의 상태 변화와 관찰자의 상태 변화가 일치할 수 있도록 구현
+
+
+### 발행/구독 패턴과의 차이점
+
+#### 관찰자 패턴
+
+- 이벤트 발생에 대해 알림 받기를 원하는 관찰자 객체가 이벤트를 발생시키는 주체 객체에 알림 대상으로서 등록되어야 한다.
+
+
+#### 발행/구독 패턴
+
+- 이벤트 소스를 하나의 객체로 보내는 방법(이벤트 집합)
+- 이벤트 알림을 원하는 구독자와 이벤트를 발생시키는 발행자 사이에 토픽/이벤트 채널을 둔다.
+- **발행자와 구독자를 각자 독립적으로 유지**한다는 것이 핵심
+- 즉, **시스템의 구성 요소 간에 느슨한 결합을 도모**한다는 것이 핵심
+- 적절한 이벤트 핸들러를 가지고 있는 구독자라면 누구나 발행자가 전파하는 토픽의 알림을 받게 할 수 있다.
+
+
+
+### 장점
+
+- 앱의 여러 구성 요소 간의 관계를 심도 있게 고민해 볼 수 있는 기회 마련
+- 각각의 요소들이 직접 연결되어 있는 곳을 파악
+- 주체와 관찰자의 관계로 대체할 수 있는 부분을 찾아낼 수 있도록 도움
+- **앱을 더 작고 느슨하게 연결된 부분으로 나눌 수 있다.**
+- **코드의 관리와 재사용성을 높일 수 있다.**
+
+
+### 또다른 장점
+
+- 클래스를 강하게 결합시키지 않으면서 관련 객체들 사이의 일관성을 유지
+- 주체와 객체 사이에 동적인 관계 형성
+- 앱의 여러 부분이 강하게 결합되어 있을 때 구현하기 까다로운 뛰어난 유연성 쉽게 구현 가능
+
+
+### 단점
+
+- 발행자와 구독자의 연결을 분리함으로써, 앱의 특정 부분들이 기대하는 대로 동작하고 있다는 것을 보장하기 어렵다.
+- 발행자는 발행을 할 뿐, 구독자가 어떤 일을 하는지 모르기 때문
+- 구독자들 역시 서로의 존재에 대해 전혀 알 수 없다.
+- 발행자를 변경하는 비용을 파악하기 어렵다.
+- 어떤 구독자가 어떤 발행자에 의존하는지 추적이 어렵다.
+
+
+## 중재자 패턴(Mediator Pattern)
+
+> 하나의 객체가 이벤트 발생 시 다른 여러 객체들에게 알림을 보낼 수 있는 패턴
+
+
+### 관찰자 패턴과의 차이
+
+- 중재자 : 하나의 객체가 다른 객체에서 발생한 특정 유형의 이벤트에 대해 알림을 받을 수 있다.
+- 관찰자 : 하나의 객체가 다른 객체에서 발생하는 다수의 이벤트를 구독할 수 있도록 한다.
+
+
+### 중재자의 정의
+
+- 여러 객체 간의 상호작용(로직과 행동)을 조율하는 객체
+- 다른 객체들의 행동과 입력에 따라 언제 어느 객체를 호출할지 결정
+- 객체 간의 워크플로우 제어
+
+
+### 이벤트 집합 패턴과의 차이
+
+- 유사점 : '이벤트'와 '서드 파티 객체'라는 두 가지 핵심 요소
+
+- 이벤트를 다루는가?
+  - 이벤트 집합 : 이름처럼 명백하다.
+  - 중재자 패턴 : 꼭 이벤트를 다룰 필요는 없다.
+- 이벤트를 왜 사용하는가?
+  - 이벤트 집합 : 이벤트 처리 그 자체를 위해 설계된 패턴
+  - 중재자 패턴 : 단순히 편리하기 때문에
+- 서브파티 객체
+  - 둘다 상호작용을 간소하기 위해 서브 파티 객체 사용
+  - 애플리케이션 로직과 워크플로우가 어디에 구현되어 있는지가 관건
+  - 이벤트 집합 : 모든 이벤트가 통과하는 중앙 허브 역할 / 알 수 없는 수의 소스에서 알 수 없는 수의 핸들러로 이벤트가 연결되도록 지원하는 역할만 한다. 실행되는 모든 워크 플로우와 비즈니스 로직은 이벤트를 발생시키는 소스와 이벤트를 처리하는 핸들러에 직접 구현
+  - 중재자 패턴 : 비즈니스 로직과 워킆플로우가 중재자 객체 내부에 집중. 자신이 보유한 정보를 바탕으로 각 객체의 메서드 호출 시점과 속성 업데이트의 필요성을 판단. 워크플로우의 각 객체는 각자의 역할을 수행하는 방법을 알고 있지만, 중재자는 보다 거시적 차원에서의 결정을 통해 객체들에게 적절한 작업 시기를 안내
+
+
+### 패턴의 활용
+
+#### 이벤트 집합의 활용
+
+직접적인 구독 관계가 많아질 경우, 또는 전혀 관련 없는 객체들 간의 소통이 필요할 때 사용
+
+
+#### 중재자 패턴의 활용
+
+- 두 개 이상의 객체가 간접적인 관계를 가지고 있는 경우
+- 비즈니스 로직이나 워크플로우에 따라 상호작용 및 조정이 필요한 경우
+- 마법사 형식의 인터페이스가 대표적 예시
+- 구현 세부사항에서 워크 플로우를 추출함으로써 보다 상위 레벨에서 워크플로우를 자연스럽게 추상화
+
+
+#### 워크플로우의 차이
+
+- 이벤트 집합 : 메뉴와 워크플로우 사이의 명확한 분리 구현 가능
+- 중재자 패턴 : 워크플로우의 관리 및 유지보수성 강화
+
+
+### 퍼사드 패턴과의 차이
+
+#### 중재자 패턴
+
+- 모듈이 명시적으로 중재자를 참조
+- 모듈 간의 상호작용을 중앙집중화
+- 본질적으로 다방향성
+
+
+#### 퍼사드 패턴
+
+- 모듈 또는 시스템에 직관적인 인터페이스를 제공
+- 하지만, 추가 기능을 구현하지 않는다.
+- 시스템 내 다른 모듈은 퍼사드의 개념을 직접적으로 인지하지 못한다.
+- 그래서 단방향성
+
+
+## 커맨드 패턴
+
+> 메서드 호출, 요청, 또는 작업을 단일 객체로 캡슐화하여 추후에 실행
+
+- 실행 시점을 유연하게 조정 가능
+- 호출을 매개변수화 가능
+- 명령을 실행하는 객체와 명령을 호출하는 객체 간의 결합을 느슨하게
+- 구체적인 클래스(객체)의 변경에 대한 유연성 향상
+
+
+### 커맨드 패턴의 기본 원칙
+
+> 명령을 내리는 객체와 명령을 실행하는 객체의 책임을 분리한다.
+
+책임을 다른 객체에 위임함으로써 역할 분리를 실현한다.
+
+
+### 장점
+
+> 인터페이스가 동일한 모든 커맨드 객체를 쉽게 교체할 수 있다.