PE Notes · SW
GoF 디자인 패턴
반복되는 객체 설계를 생성·구조·행위 세 칸으로 나누고, 팩토리·데코레이터·옵저버처럼 자주 쓰는 패턴의 역할과 범위를 정리합니다.
“옵저버로 알리자” 한 마디가 클래스 상자 여러 개보다 빠릅니다. 은 모듈 안에서 반복되는 설계 문제의 역할과 협력입니다. GoF 네 저자가 1994년 책에 스물셋을 모아 생성·구조·행위로 갈랐습니다. 시스템 전체의 스타일(레이어, 마이크로서비스)과는 범위가 다릅니다. 스타일 글이 큰 말을 고르면, 여기는 나뉜 칸 안의 해법입니다.
세 칸, 스물셋
생성은 객체를 누가 어떻게 만드는지 감춥니다. 구조는 클래스와 객체를 어떻게 붙이는지입니다. 행위는 누가 무엇을 하고 어떻게 알리는지입니다. 숫자는 생성 5, 구조 7, 행위 11입니다.
의 예는 셋이면 충분합니다. 는 생성 종류를 하위 타입이 고릅니다. 로그를 파일로 보낼지 콘솔로 보낼지를 호출부가 몰라도 됩니다. 빌더는 단계가 많은 객체를 순서 있게 쌓습니다. 은 인스턴스를 하나로 묶습니다. 설정·연결 풀처럼 상태가 하나여야 할 때입니다. 전역과 비슷해 시험과 숨은 결합이 대가입니다.
은 붙이는 방법입니다. 는 안 맞는 인터페이스를 번역합니다. 레거시·외부 라이브러리 앞에 자주 둡니다. 는 상속 대신 감싸서 기능을 겹칩니다. 스트림에 버퍼·암호를 쌓는 길이 그 예입니다. 조합이 상속보다 안전한 자리입니다. 는 복잡한 안에 얇은 문 하나를 냅니다. 게이트웨이처럼 호출부를 단순하게 둡니다.
은 책임의 이동입니다. 는 상태가 바뀌면 구독자에게 알립니다. 화면 갱신, 이벤트 버스가 가깝습니다. 주체와 관찰자가 서로를 구체 타입으로 안 붙으면 결합이 낮습니다. 은 알고리즘을 객체로 갈아 끼웁니다. 결제 수단·정렬을 분기 나열 대신 다형으로 고릅니다. 커맨드는 요청을 객체로 남겨 실행 취소와 큐가 가능해집니다.
| 칸 | 관심 | 예 |
|---|---|---|
| 생성 | 만드는 방법 | 팩토리 메서드, 빌더, 싱글톤 |
| 구조 | 붙이는 방법 | 어댑터, 데코레이터, 파사드 |
| 행위 | 역할과 알림 | 옵저버, 전략, 커맨드 |
MVC의 컨트롤러가 중재에 가깝고, 리액트 상태 구독은 옵저버에 가깝습니다. 이름은 빌려도 적용 범위를 먼저 적습니다. UI 아키텍처 패턴과 클래스 하나의 GoF를 한 상자에 넣지 않습니다.
언제 꺼내고 언제 참을까
패턴은 소통의 짧은 이름입니다. 없는 문제를 패턴으로 채우면 클래스만 늘어납니다. 생성 유연성이 필요하면 팩토리, 옛 인터페이스를 살리려면 어댑터, 알림이 여러 곳이면 옵저버가 후보입니다. 상속으로 기능을 겹쌓기 전에 데코레이터와 조합을 봅니다. 마이크로서비스의 바깥 문은 파사드, 레거시 연동은 어댑터, 이벤트는 옵저버 쪽으로 읽으면 됩니다.
답안은 세 분류와 개수, 각 칸에서 두세 개의 의도, 그리고 스타일·UI 패턴과의 범위 차이를 한 표로 닫습니다.