Problem
먼저 코드가 겪는 반복 문제와 변경 압력을 구체적으로 적습니다.
디자인 패턴 선택 기준표
패턴은 이름을 외워 적용하는 공식이 아니라 반복되는 설계 문제를 보고 결합도와 변경 비용을 낮추는 선택지입니다.
Forces
공유 상태, 생성 분기, 알림 전파, 정보 은닉 같은 힘을 구분합니다.
Pattern
문제 성격에 맞는 싱글톤, 팩토리, 옵저버, 모듈 패턴을 고릅니다.
Tradeoff
복잡도 증가와 유연성 확보 사이의 균형을 검토합니다.
앱 전역 설정처럼 하나만 있어야 하는 상태에 제한적으로 사용합니다.
객체 생성 조건이 늘어날 때 호출부가 생성 세부사항을 몰라도 되게 합니다.
상태 변화 알림을 여러 대상에 전파하되 직접 의존을 줄입니다.
클로저나 ESM으로 내부 구현과 공개 API를 분리합니다.
패턴 문제 유형 선택
지금 문제는 인스턴스 공유, 생성 분기, 이벤트 전파, 정보 은닉 중 무엇에 가까운가를 봅니다.
디자인 패턴 선택 실수 방지
작은 조건문 하나를 없애려고 과한 구조를 도입하면 읽기 비용이 더 커집니다.
디자인 패턴 선택 기준표
패턴 이름보다 적용 전후의 의존성 변화와 테스트 용이성을 설명합니다.