1. 생성(Creational) 패턴 🔍
1. Singleton (싱글톤)
| 항목 | 요점 |
|---|
| 문제정의 | 객체를 생성해야 하는데, 생성할 클래스가 유동적이거나 클라이언트가 어떤 구체 클래스를 생성해야 할지 모르거나 알 필요가 없을 때, 객체 생성을 어떻게 설계해야 하는가? 이때, 그 객체는 반드시 시스템 전체에서 하나만 존재해야 한다면 어떻게 보장할 것인가? |
| 일반화 개념 | 객체를 하나만 생성하고, 해당 인스턴스에 전역 접근 지점(Global Access Point) 을 제공하며, 동시성 문제 없이 유일 인스턴스를 보장하는 구조로 일반화됨 |
| 일반화된 문제 | 설정 객체(Config), 로깅 시스템(Logger), 데이터베이스 커넥션풀, 이벤트 디스패처처럼 전역에서 하나만 존재해야 하는 컴포넌트를 안전하게 제공해야 하는 경우 |
| 구현 메커니즘 | private 생성자 + static 인스턴스 변수 + public static getInstance() 메서드 조합으로 단일 인스턴스 제공.
고급 구현으로는 synchronized, DCL(Double-Checked Locking), 정적 내부 클래스(Holder idiom) 등을 사용해 thread-safe 보장 |
2. Factory Method (팩토리 메서드)
| 항목 | 요점 |
|---|
| 문제정의 | 객체를 생성해야 하는데, 생성할 클래스가 유동적이거나 클라이언트가 어떤 구체 클래스를 생성해야 할지 모르거나 알 필요가 없을 때, 객체 생성을 어떻게 설계해야 하는가? |
| 일반화 개념 | 객체 생성 책임을 클라이언트가 아닌 서브클래스에게 위임하여, 생성될 구체 클래스와 클라이언트를 분리한다. 생성 알고리즘은 상위 클래스가 정의하고, 구체 생성은 하위 클래스가 담당한다. |
| 일반화된 문제 | 플랫폼별 UI 컴포넌트 생성, DB 커넥터 추상화, 파서 전략 선택 등 런타임에 생성할 객체 종류가 바뀌거나 확장 가능해야 하는 상황 |
| 구현 메커니즘 | Product 인터페이스, ConcreteProduct 클래스, 팩토리 메서드 createProduct()를 선언하는 Creator 추상 클래스, 그리고 이를 구현하는 ConcreteCreator 클래스 구조. 클라이언트는 Creator만 의존하고 객체 생성은 ConcreteCreator가 수행 |
- 팩토리 메서드 패턴은 객체 생성 책임을 서브클래스에게 위임해서, 확장에 열리고 수정에 닫힌 구조(OCP) 를 만드는 생성 패턴
1
2
| DocumentService service = new PdfDocumentService();
service.printDocument(); // 출력: PDF 출력
|
- 비즈니스로직에서는 팩토리메서드를 호출하고, 팩토리메서드에서 구현체의 객체를 생성하여 메소드를 대신 호출하는 패턴
- 비즈니스로직은 비즈니스 업무만 집중(어떤 구현체가 뭘 어떻게 하는지 중요 X), 팩토리메서드는 객체를 생성하여 필요한 메소드를 호출하는 것만 집중.
3. Abstract Factory (추상 팩토리)
| 항목 | 요점 |
|---|
| 문제정의 | 관련성 있거나 독립적인 여러 객체들을 구체 클래스에 의존하지 않고 가족 단위로 생성해야 할 때, 객체 생성을 어떻게 설계해야 하는가? |
| 일반화 개념 | 서로 연관된 객체들의 구체 클래스를 지정하지 않고, 객체 군(family)을 생성하는 인터페이스를 제공한다. 클라이언트는 구체 공장을 통해 객체군을 생성하고 조합한다. |
| 일반화된 문제 | 서로 호환되는 여러 객체(예: GUI 위젯의 버튼, 체크박스, 텍스트필드)를 한 세트로 생성해야 하며, 다른 세트로 교체할 때 클라이언트 코드를 수정하지 않아야 하는 상황 |
| 구현 메커니즘 | AbstractFactory 인터페이스가 여러 종류의 추상 제품(Product) 생성 메서드를 정의하고, ConcreteFactory가 이를 구현한다. 클라이언트는 팩토리 객체를 통해 제품군을 생성하여 사용한다. |
- 비즈니스 로직에서는 Abstract Factory의 메서드를 호출하고, Abstract Factory는 관련된 Factory Method들을 한 번에 호출하여 서로 관련 있는 객체들을 일관되게 생성 및 호출
- 일반 Factory Method 패턴과 유사하지만, Abstract Factory는 관련 객체들(제품군)을 일괄적으로 생성하는 데 초점
4. Builder (빌더)
| 항목 | 요점 | | ——- | ——————— | | 문제정의 | 복잡한 객체를 단계별로 생성해야 하는데, 생성 과정이 여러 단계로 나뉘고, 객체 내부 표현 방식이 다양할 때, 객체 생성을 어떻게 설계할 것인가? | | 일반화 개념 | 객체 생성 과정을 분리하여, 동일한 생성 절차에서 서로 다른 표현의 객체를 만들 수 있도록 일반화한다. 빌더는 각 단계별 생성 책임을 갖고, 디렉터는 생성 순서를 관리한다. | | 일반화된 문제 | 복잡한 문서 생성, 조립 과정이 복잡한 제품(예: 자동차, 컴퓨터), 다양한 옵션을 가진 객체 생성 등 여러 단계와 조합이 필요한 객체 생성 상황 | | 구현 메커니즘 | Builder 인터페이스(또는 추상 클래스)가 단계별 생성 메서드 정의, ConcreteBuilder가 구체 생성 구현, Director가 생성 순서 및 절차 관리, 클라이언트는 Director에게 요청 |
- 복잡한 객체를 생성할 때(생성자에 많은 인자나 복잡한 초기화 로직)이 필요한 경우 객체 생성 과정을 별도의 Builder 클래스로 분리하여, 단계적으로 필요한 값만 설정하고 최종적으로 객체를 생성하는 유연하고 가독성 높은 패턴
5. Prototype (프로토타입)
| 항목 | 요점 |
|---|
| 문제정의 | 객체 생성 비용이 크거나 복잡한 초기화가 필요한 객체를 기존 인스턴스를 복제해서 새 객체를 생성해야 할 때, 객체 생성을 어떻게 설계할 것인가? |
| 일반화 개념 | 기존 객체를 복제(clone)하여 새로운 객체를 생성하는 방식을 일반화한다. 복제는 객체 내부 상태를 복사하며, 생성 비용을 줄일 수 있다. |
| 일반화된 문제 | 대량 객체 생성이 필요한 그래픽 객체, 복잡한 설정을 가진 객체, 상태가 초기화된 객체를 복제해 여러 개 생성할 때 |
| 구현 메커니즘 | Prototype 인터페이스가 clone() 메서드 정의, ConcretePrototype이 clone()을 구현하여 자기 자신의 복사본을 반환, 클라이언트는 복제 메서드를 호출하여 객체 생성 |
2. 구조(Structural) 패턴 🔍
1. Adapter (어댑터)
| 항목 | 요점 |
|---|
| 문제정의 | 기존 클래스의 인터페이스가 클라이언트가 기대하는 인터페이스와 달라서 직접 사용할 수 없을 때, 인터페이스 호환 문제를 어떻게 해결할 것인가? |
| 일반화 개념 | 기존 클래스의 인터페이스를 클라이언트가 요구하는 인터페이스로 변환하는 래퍼(Wrapper)를 만들어 호환성을 제공한다. |
| 일반화된 문제 | 레거시 코드 재사용, 외부 라이브러리 통합, 다른 인터페이스를 가진 클래스 연결 등 인터페이스 차이 해결 상황 |
| 구현 메커니즘 | Adapter 클래스가 기존 클래스(Adaptee)를 포함하거나 상속받아 클라이언트가 기대하는 인터페이스로 변환하여 위임 처리 |
- Adapter는 인터페이스가 달라 직접 호출이 불가능한 경우, 중간에서 타입 변환 및 메서드 호출을 조정하여 연결해주는 역할
2. Bridge (브릿지)
| 항목 | 요점 |
|---|
| 문제정의 | 추상화와 구현이 독립적으로 변할 수 있도록 설계해야 할 때, 둘을 어떻게 분리할 것인가? |
| 일반화 개념 | 기 능을 처리하는 클래스와 구현을 담당하는 추상 클래스로 클래스 계층으로 분리하고, 추상화는 구현 객체에 대한 참조를 유지하여 독립적인 확장을 가능하게 함. |
| 일반화된 문제 | 다양한 구현체와 추상화 조합이 필요하거나, 기능과 구현이 자주 변경되어 확장성이 필요한 상황 |
| 구현 메커니즘 | Abstraction 클래스가 Implementor 인터페이스를 참조하고, 구체 구현체는 Implementor를 구현하여 기능 분리 및 위임 |
- 이미 구현된 ‘구현체(Implementation)’가 있고, 그 구현체를 새로운 추상 인터페이스(Abstraction)에서 사용할 수 있게 “다리(Bridge)” 역할
- Device타입의 TV가 있을때, 이것을 생성자 파라미터로 하는 RemoteControl을 만들어서, Device객체가 바뀌어도 RemoteControl타입에서 사용하던 기능은 유지하려는 패턴
- RemoteControl은 최초에 추상화하고자 했던 객체의 기능에 가깝고,
- Device 객체는 실제로 어떻게 기능을 사용할지에 대한 구현에 가깝게됨.
3. Composite (컴포지트)
| 항목 | 요점 |
|---|
| 문제정의 | 객체들을 트리 구조로 구성하여 부분-전체 계층을 표현하고, 클라이언트가 개별 객체와 복합 객체를 동일하게 처리할 수 있도록 어떻게 설계할 것인가? |
| 일반화 개념 | 리프(Leaf)와 컴포지트(Composite)를 동일한 인터페이스로 처리하고, 컴포지트는 자식 객체들을 관리하여 재귀적 처리가 가능하도록 한다. |
| 일반화된 문제 | UI 트리, 파일 시스템, 조직도 등 계층적 데이터 구조에서 부분과 전체를 일관된 방식으로 다뤄야 하는 상황 |
| 구현 메커니즘 | Component 인터페이스 정의, Leaf와 Composite가 이를 구현하며 Composite는 자식 컴포넌트를 포함하고 관리한다. |
- 단일 객체(Leaf)와 객체들의 집합체(Composite)를 동일한 인터페이스로 다룰 수 있게 만드는 것
4. Decorator (데코레이터)
| 항목 | 요점 |
|---|
| 문제정의 | 기존 객체에 동적으로 새로운 책임(기능)을 추가해야 할 때, 상속을 사용하지 않고 어떻게 확장할 것인가? |
| 일반화 개념 | 기존 객체를 감싸는(wrapper) 데코레이터 객체를 만들어, 기능 추가나 변경을 위임과 조합으로 처리한다. |
| 일반화된 문제 | 기능 확장이 빈번하거나 조합 가능한 책임을 동적으로 추가해야 하는 상황 |
| 구현 메커니즘 | Component 인터페이스와 ConcreteComponent, Decorator 클래스를 정의하고, Decorator가 Component를 포함하여 기능을 확장한다. |
- 기준이 되는 객체를 만들고 그것을 기준으로 주변 컴포넌트들의 값을 조정
5. Facade (퍼사드)
| 항목 | 요점 |
|---|
| 문제정의 | 복잡한 서브시스템 인터페이스를 단순하고 일관된 인터페이스로 제공하여 클라이언트가 서브시스템을 쉽게 사용할 수 있도록 어떻게 설계할 것인가? |
| 일반화 개념 | 여러 복잡한 클래스들을 감싸는 단순화된 인터페이스(Facade)를 제공하여 서브시스템과 클라이언트 간의 결합도를 낮춘다. |
| 일반화된 문제 | 복잡한 라이브러리, 여러 클래스로 구성된 서브시스템 사용 시 진입점 통일 및 사용 편의성 필요 |
| 구현 메커니즘 | Facade 클래스가 서브시스템 클래스들의 객체를 보유하고, 필요한 기능을 위임하며 단일 진입점을 제공한다. |
- 여러 개의 객체(서브시스템)들이 협력해서 하나의 기능을 수행할 때, 그 복잡한 내부 객체들을 하나의 단순한 인터페이스(추상화 계층)로 감싸서 클라이언트가 쉽고 일관되게 사용할 수 있도록 만드는 패턴
6. Flyweight (플라이웨이트)
| 항목 | 요점 |
|---|
| 문제정의 | 대량의 객체를 생성해야 하는데, 메모리 낭비를 줄이고 동일한 상태(내부 상태)를 공유하여 객체 수를 줄이는 방법은? |
| 일반화 개념 | 공유 가능한 상태(내부 상태)를 객체간에 공유하고, 외부 상태는 클라이언트가 별도로 관리하여 메모리를 절약한다. |
| 일반화된 문제 | 문자 처리, 그래픽 객체, 게임 오브젝트 등 동일하거나 유사한 데이터가 다수 존재하는 경우 |
| 구현 메커니즘 | Flyweight 인터페이스와 ConcreteFlyweight, FlyweightFactory를 구현하여 공유 객체를 관리하고 외부 상태를 분리한다. |
- 많은 수의 유사한 객체를 생성해야 할 때, 공통된 부분은 하나의 공유 객체로 만들고, 각 객체가 다른 상태(내부 상태)는 별도로 관리하여 메모리를 절약하는 패턴
7. Proxy (프록시)
| 항목 | 요점 |
|---|
| 문제정의 | 다른 객체에 대한 접근을 제어하거나, 객체 생성 비용을 지연시키고, 기능 확장(캐싱, 접근 제어 등)을 위해 대리자 역할을 하는 객체를 어떻게 설계할 것인가? |
| 일반화 개념 | 실제 객체에 대한 접근을 제어하는 프록시 객체를 만들고, 클라이언트는 프록시를 통해 실제 객체를 간접적으로 조작한다. |
| 일반화된 문제 | 원격 접근(Remote Proxy), 접근 권한 제어(Security Proxy), 지연 초기화(Lazy Proxy), 캐싱(Caching Proxy) 등 다양한 상황에서 활용 |
| 구현 메커니즘 | Proxy 클래스가 Subject 인터페이스를 구현하고, 실제 객체에 요청을 위임하며 추가 기능(권한 검사, 로깅 등)을 수행한다. |
- Proxy는 메인 비즈니스 로직과 실제 객체 사이에 위치해서, 접근 통제 및 부가 기능을 제공하는 대리자 역할
3. 행위(Behavioral) 패턴 🔍
1. Command (커맨드 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 실행될 기능과 실행 요청자를 분리하고, 실행 명령을 캡슐화하여 요청, 큐잉, 취소 등을 유연하게 처리하려면 어떻게 설계할 것인가? |
| 일반화 개념 | 명령(Command) 객체에 수행할 작업을 캡슐화하고, 요청자(Invoker)와 수행자(Receiver)를 분리한다. |
| 일반화된 문제 | 작업 실행 지연, 로그 기록, 작업 취소, 스케줄링, 트랜잭션 처리 등에서 유용 |
| 구현 메커니즘 | Command 인터페이스 정의, ConcreteCommand가 Receiver의 작업 호출, Invoker가 Command 객체를 호출 |
- TV(수신자)와 리모컨(요청자)을 직접 연결할 경우, 리모컨은 TV의 내부 기능을 모두 알아야 하므로, 양측의 결합도가 높아지고 유연성이 떨어찜.
- Command 객체를 도입하면, 리모컨(Invoker)은 단지 execute()만 호출하고, TV(Receiver)는 해당 Command 내부에서만 호출되므로 양측은 간접적으로 연결되고, 결합도가 낮아짐.
- 또한 직접 연결 구조에서는 요청이 즉시 실행되기 때문에,요청을 저장하거나 지연 실행하거나 취소하는 등의 추가 제어가 어려움. Command 패턴은 요청 자체를 객체로 처리함으로써 복합 처리, 실행 취소 등의 다양한 처리가 가능함.
2. Chain of Responsibility (책임 연쇄 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 요청을 처리할 객체가 여러 개이고, 누가 처리할지 모를 때, 객체들 사이에 요청을 전달하는 책임을 어떻게 분산할 것인가? |
| 일반화 개념 | 요청을 처리할 수 있는 객체들이 연결된 체인을 형성하고, 각 객체는 자신이 처리할 수 없으면 다음 객체에 요청을 전달한다. |
| 일반화된 문제 | 이벤트 처리, 예외 처리, 필터링 시스템 등 여러 객체가 요청을 순차적으로 처리해야 할 때 |
| 구현 메커니즘 | Handler 인터페이스 정의, ConcreteHandler가 실제 처리, 각 Handler가 다음 Handler에 대한 참조를 유지하여 요청 전달 |
- 요청을 처리할 수 있는 객체들을 연쇄적으로 연결하여, 어떤 객체가 요청을 처리할지는 실행 시점에 결정되도록 하는 패턴
3. Strategy (전략 패턴)
| 항목 | 요점 | | ——- | ——————————- | | 문제정의 | 동일한 문제를 해결하는 다양한 알고리즘이 있고, 런타임에 알고리즘을 교체해야 할 때 어떻게 설계할 것인가? | | 일반화 개념 | 알고리즘들을 각각 별도의 전략 클래스에 캡슐화하고, Context가 전략 객체를 이용해 알고리즘을 실행한다. | | 일반화된 문제 | 정렬 방식 변경, 경로 탐색 알고리즘 교체, 데이터 압축 방법 다양화 등 | | 구현 메커니즘 | Strategy 인터페이스, ConcreteStrategy 클래스들, Context 클래스 구현 |
- Strategy 패턴은 실행 컨텍스트(Context)에 전략 객체(Strategy)를 주입함으로써, 동일한 인터페이스를 따르는 다양한 전략 클래스들을 동적으로 선택·교체하며 행위를 유연하게 수행할 수 있게 해주는 디자인 패턴
4. State (상태 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 객체의 상태에 따라 행위가 변하고, 상태별로 조건문을 많이 사용해 복잡해질 때 상태별 행위를 별도의 클래스로 분리하려면 어떻게 설계할 것인가? |
| 일반화 개념 | 상태별 행위를 각각의 상태 클래스에 캡슐화하고, Context가 현재 상태 객체를 참조하여 행위를 위임한다. |
| 일반화된 문제 | 게임 캐릭터 상태, 네트워크 연결 상태, 문서 편집 상태 등 상태 변화에 따른 행위 변화 요구 |
| 구현 메커니즘 | State 인터페이스, ConcreteState 클래스들, Context 클래스 구현 |
특정 상태에 따른 메소드 실행을 구분할 때, 비즈니스 로직에서 직접 필드 값을 변경하지 않고, 상태를 나타내는 상태 클래스(State Class)와 상태 전환(변경) 로직을 수행하는 상태 변경 클래스(State Transition Class)를 별도로 생성
상태 클래스는 내부에 상태 변경 클래스를 필드로 가지고 있으며, 비즈니스 로직에서 상태 클래스의 메서드를 호출하면, 해당 상태 변경 클래스가 상태 변경 로직을 실행하고, 필드의 상태를 변경 처리
5. Template Method (템플릿 메서드)
| 항목 | 요점 |
|---|
| 문제정의 | 알고리즘의 구조는 일정하지만 세부 단계는 하위 클래스에서 구현해야 할 때, 알고리즘 골격을 어떻게 재사용할 것인가? |
| 일반화 개념 | 상위 클래스가 알고리즘의 골격을 정의하고, 하위 클래스가 구체적인 단계를 구현하는 템플릿 메서드를 제공한다. |
| 일반화된 문제 | 공통 프로세스가 있고, 세부 동작이 다양한 경우 예: 데이터 처리, 문서 생성, 게임 룰 적용 |
| 구현 메커니즘 | 추상 클래스에 템플릿 메서드 정의, 추상 메서드 또는 후크 메서드를 하위 클래스에서 구현 |
- 일반적인 상속관계(자식 → 부모 호출)와 정반대 방향의 흐르지만, Template Method는 반대로 부모가 자식의 메서드를 호출하려고 abstract를 쓰는 방식 => 역제어(Inversion of Control)구조
- 부모객체의 공통 final Method를 사용하기 위해 필요한 abstract Method를 구현하기 위해서 자녀 객체를 이용하는 구조
6. Observer (옵저버 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 한 객체의 상태 변화가 있을 때, 의존하는 여러 객체에 자동으로 통보하고 동기화하려면 어떻게 설계할 것인가? |
| 일반화 개념 | Subject가 상태 변화를 알리고, 다수 Observer들이 구독하여 상태 변화를 자동으로 수신 및 반영한다. |
| 일반화된 문제 | 이벤트 시스템, MVC 패턴의 View-Model 연동, 분산 시스템 상태 알림 |
| 구현 메커니즘 | Subject 인터페이스, Observer 인터페이스 정의, ConcreteSubject, ConcreteObserver 구현 |
- 공통 적용이 필요한 대상들(Observer들)을 자료구조에 담아두고, 상태 변화가 있을 때, 해당 목록 전체에게 일괄적으로 통지하여 반응하게 하는 구조
| 항목 | 요점 |
|---|
| 문제정의 | 여러 객체들이 복잡하게 서로 통신할 때, 직접 참조와 상호작용을 줄이고, 중앙 집중식 통신을 통해 결합도를 낮추려면 어떻게 설계할 것인가? |
| 일반화 개념 | 중재자 객체가 객체들 간의 통신을 조율하고, 객체들은 중재자와만 통신하여 객체 간 결합도를 낮춘다. |
| 일반화된 문제 | GUI 컴포넌트 간 이벤트 처리, 채팅 서버, 통신 프로토콜 등 복잡한 상호작용 관리 |
| 구현 메커니즘 | Mediator 인터페이스 정의, ConcreteMediator가 중재 로직 구현, Colleague들이 Mediator 참조 |
- Mediator 클래스를 정의하고, 개별 기능 클래스들은 특정 동작을 수행할 때 Mediator 클래스의 메서드를 호출, Mediator 클래스는 자신과 연결되어 있는 다른 클래스들의 특정 기능을 호출하여 조정하며,각 기능 클래스들끼리는 직접 서로를 참조하지 않고, 중재자인 Mediator를 통해 간접적으로 협력함.
- 메신저
- Observer 패턴은 상태전달하는 구조
8. Iterator (반복자 패턴)
| 항목 | 요점 | | ——- | —– | | 문제정의 | 집합 객체의 내부 구조를 노출하지 않고, 그 원소들에 순차적으로 접근하는 방법을 어떻게 설계할 것인가? | | 일반화 개념 | 반복자 객체를 별도로 만들어, 집합 객체 내부 구조와 관계없이 원소를 탐색할 수 있도록 분리한다. | | 일반화된 문제 | 컬렉션 순회, 배열, 리스트, 트리 등 다양한 데이터 구조에서 일관된 탐색 인터페이스 제공 | | 구현 메커니즘 | Iterator 인터페이스 정의, ConcreteIterator가 구체적 순회 구현, Aggregate가 Iterator 생성 |
- 자료구조에 저장된 요소들을 하나씩 순서대로 접근할 때 사용함.
1
2
3
| [Collection] -- iterator() --> [Iterator]
↑ ↓
저장만 담당 요소를 순서대로 제공
|
9. Memento (메멘토 패턴)
| 항목 | 요점 | | ——- | ———————- | | 문제정의 | 객체 상태를 캡슐화해 저장하고, 필요할 때 이전 상태로 복원하려면 어떻게 설계할 것인가? | | 일반화 개념 | Originator가 상태를 Memento 객체에 저장하고, Caretaker가 Memento를 관리하며 필요 시 복원 요청 | | 일반화된 문제 | Undo 기능, 상태 기록 및 복원, 트랜잭션 롤백 등 | | 구현 메커니즘 | Originator, Memento, Caretaker 클래스 분리 및 역할 정의 |
- Memento 패턴은 객체의 상태를 캡슐화한 채로 저장하고, 나중에 해당 상태로 복원할 수 있도록 해주는 구조
10. Visitor (방문자 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 객체 구조가 복잡하고, 그 구조에 대해 수행할 연산이 자주 바뀔 때, 객체 구조와 연산을 분리하려면 어떻게 설계할 것인가? |
| 일반화 개념 | 연산을 Visitor 객체로 캡슐화하고, 객체 구조는 Element 인터페이스로 분리하여 Visitor가 다양한 연산을 수행하도록 한다. |
| 일반화된 문제 | 컴파일러 구문 트리 처리, 복잡한 자료구조 순회 및 다양한 연산 적용 |
| 구현 메커니즘 | Visitor 인터페이스, ConcreteVisitor, Element 인터페이스 및 ConcreteElement 구현 |
- 객체가 자신을 매개변수로 넘겨 호출된 Visitor의 타입별 오버로딩된 메서드에서 연산을 수행하고 결과를 반환하는 구조
11. Interpreter (인터프리터 패턴)
| 항목 | 요점 |
|---|
| 문제정의 | 특정 언어나 문법에 대해 해석/평가기를 만들 때, 문법 규칙을 표현하고 해석하는 구조를 어떻게 설계할 것인가? |
| 일반화 개념 | 문법을 클래스 계층으로 표현하고, 각 클래스가 자신의 문법 규칙을 해석하는 interpret() 메서드를 구현한다. |
| 일반화된 문제 | 수식 계산기, SQL 해석기, 정규식 파서, 문법 기반 처리기 등 |
| 구현 메커니즘 | AbstractExpression, TerminalExpression, NonterminalExpression 클래스로 문법 구성, 트리 구조로 평가 |
- 문법 규칙을 클래스로 표현하여, 문장 또는 표현식을 객체 트리로 구성하고 해석할 수 있도록 만든 패턴
- 패턴에서 클래스가 Interpreter 인터페이스(또는 추상 클래스)를 구현한다는 것