GoF 디자인 패턴: 생성·구조·행위
GoF 디자인 패턴 23개를 생성·구조·행위로 분류하고 유사 패턴의 의도를 구분한다.
디자인 패턴
GoF 디자인 패턴 분류도
디자인 패턴은 반복해서 나타나는 설계 문제에 대해 검증된 문제·해결 구조·결과를 이름 붙여 정리한 것이다. 완성된 소스 코드나 특정 라이브러리 자체가 아니다.
GoF 패턴은 목적에 따라 생성 5개, 구조 7개, 행위 11개로 분류된다.
생성 패턴 5개
| 패턴 | 핵심 의도 |
|---|---|
| Abstract Factory | 서로 관련된 객체 제품군을 구체 클래스 없이 생성 |
| Builder | 복잡한 객체의 생성 절차와 표현을 분리 |
| Factory Method | 객체 생성 결정을 하위 클래스에 위임 |
| Prototype | 기존 원형 객체를 복제하여 생성 |
| Singleton | 클래스의 인스턴스를 하나로 제한하고 접근점 제공 |
빠른 구분
- 제품군을 함께 바꿈 → Abstract Factory
- 같은 조립 절차로 다른 표현을 만듦 → Builder
- 하위 클래스가 생성 타입 결정 → Factory Method
- 복제 비용이 유리함 → Prototype
- 하나의 인스턴스 접근을 통제 → Singleton
구조 패턴 7개
| 패턴 | 핵심 의도 |
|---|---|
| Adapter | 호환되지 않는 인터페이스를 기대하는 인터페이스로 변환 |
| Bridge | 추상화와 구현을 분리하여 각각 독립적으로 변경 |
| Composite | 부분과 전체를 동일한 인터페이스로 다룸 |
| Decorator | 객체를 감싸며 기능을 동적으로 추가 |
| Facade | 복잡한 서브시스템에 단순한 대표 인터페이스 제공 |
| Flyweight | 많은 객체의 공통 상태를 공유하여 메모리 절약 |
| Proxy | 실제 객체의 대리자를 두어 접근 제어·지연 생성 등을 수행 |
혼동 구분
- Adapter: 기존 인터페이스 변환
- Bridge: 두 변화 축을 분리
- Decorator: 같은 인터페이스로 기능 추가
- Proxy: 실제 객체 접근을 대리·통제
- Facade: 여러 서브시스템을 단순하게 사용하는 창구
Composite는 트리 구조에서 잎과 복합 객체를 같은 방식으로 다룬다. Flyweight는 공유 가능한 내부 상태와 객체마다 달라지는 외부 상태를 구분한다.
행위 패턴 11개
| 패턴 | 핵심 의도 |
|---|---|
| Chain of Responsibility | 요청을 처리자 사슬에 전달 |
| Command | 요청을 객체로 캡슐화 |
| Interpreter | 간단한 언어의 문법과 해석 규칙 표현 |
| Iterator | 내부 구조를 노출하지 않고 순회 |
| Mediator | 객체 간 복잡한 상호작용을 중재자에 집중 |
| Memento | 캡슐화를 깨지 않고 객체 상태 저장·복원 |
| Observer | 한 객체의 변화가 여러 관찰자에게 통지 |
| State | 내부 상태에 따라 객체의 행동 변경 |
| Strategy | 교체 가능한 알고리즘군을 캡슐화 |
| Template Method | 알고리즘 골격은 상위 클래스, 일부 단계는 하위 클래스에서 구현 |
| Visitor | 객체 구조를 바꾸지 않고 새로운 연산 추가 |
자주 혼동하는 행위 패턴
- State vs Strategy: 구조는 비슷하지만 State는 내부 상태에 따른 행동 변화, Strategy는 외부에서 알고리즘 선택이 중심이다.
- Strategy vs Template Method: Strategy는 합성으로 알고리즘 객체를 교체하고, Template Method는 상속으로 일부 단계를 재정의한다.
- Mediator vs Observer: Mediator는 상호작용 규칙을 중앙에서 조정하고, Observer는 상태 변화의 일대다 통지가 중심이다.
- Memento vs Command: Memento는 상태 저장·복원, Command는 요청의 객체화가 중심이다.
- Iterator vs Visitor: Iterator는 순회, Visitor는 요소 구조에 새로운 연산을 추가한다.
패턴 선택 방법
- 문제의 변화 지점을 찾는다.
- 객체 생성·구조 조합·행위 협력 중 어느 범주인지 본다.
- 참여 객체와 책임을 확인한다.
- 장점뿐 아니라 복잡성·결합 증가 같은 결과도 검토한다.
패턴을 많이 적용한다고 좋은 설계가 되는 것은 아니다. 문제와 변화 가능성이 분명할 때 사용한다.