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