Design Patterns

Creation Patterns

Adapter (aka. Wrapper)

• Client가 필요한 Target의 역할을 Adapter로 구현한다.

• Adapter가 Adaptee를 이용하는 방식은 상속(inherit) 위임(delegate) 두가지가 있다.
• 상속은 implementation, 위임은 aggregation 으로 구현한다.
• 일반적으로 위임이 부작용이 적은데, 상속을 사용할 경우 상위 class의 내부 구현에 의존할 가능성이 높기 때문이다.

• 기존 코드를 변경 없이 그대로 쓰고 싶은 경우 필요한 인터페이스에 맞춰서 Adapter를 구현한다.

• 또는 새로운 버전의 코드만 유지보수하고 싶다면 새로운 버전의 구현을 Adaptee로, 구버전의 인터페이스를 Target로하여 Adapter를 구현한다.

Factory Method

• Instance를 생성하는 방식을 super class에서 결정하되 실질적인 생성은 child class에서 담당한다.
• 여기서 생성하는 방식이란, 어떤 method를 어떤 parameter로 호출하여 instance를 생성하는지에 대한 부분이다.
• 예: CardFactory는 createCard() method를 호출하여 Card instance를 생성한다.

String.valueOf(1);
List.of(”1”, “2”, “3”);
Arrays.asList(new int[]{1, 2, 3});

Abstract Factory

• Factory pattern과 사실상 동일하지만 Factory의 구체적인 구현체(ConcreteFactory)를 호출하는 방식에서 차이가 있다.
• Factory pattern에서는 Client에서 ConcreteFactory를 직접적으로 호출한다.
• 하지만 Abstract Factory에서는 ConcreteFactory를 reflection으로 생성하므로 직접적으로 ConcreteFactory를 컴파일하여 링킹하지 않게 된다.

package factory;

public abstract class Factory {
    public static Factory getFactory(String className) {
        Factory factory = null;
        try {
            factory = (Factory)Class.forName(className);
        } catch (ClassNotFoundException e) {
            System.out.println(className + " was not found");
        } catch (Exception e) {
            e.printStackTrace();
        }
        return factory;
    }
    public abstract Link createLink(String caption, String url);
    public abstract Card createCard(String title);
    public abstract Page createPage(String title, String author);
};

• Factory pattern에서는 제품, Abstract Factory pattern에서는 여러가지 부품을 생성하는 것으로 비유하기는 했는데 사실 양쪽다 생성하는 인스턴스 타입의 가짓수 차이만 있을 뿐 동일한 생성 방식임을 가정할 수 있다.
• 물론 Factory method pattern의 경우 concrete class로 부터 직접 instance를 생성하므로 Abstract Factory pattern과는 확연히 구분된다.

• 새로운 부품을 추가하는 경우 모든 ConcreteFactory에 method 추가를 위한 변경이 필요하다고 하였는데 사실 이 부분은 factory method의 기본 구현을 통해서 회피할 수 있지 않을까 한다.

public class DefaultFactory extends Factory {
    public Link createLink(String caption, String url) {
        throw new UnsupportedOperationException();
    }
    ...
};

Singleton

• instance가 하나만 존재한다는 것을 보증하는 패턴.

• 생성자는 private로 제한하고 유일한 instance를 돌려주는 static method (보통 getInstance)를 정의한다.
• getInstance는 static factory method의 일종이다.
• static factory method 처럼 parameter를 받아서 해당 parameter에 대응되는 유일한 instance를 돌려주는 것도 가능하다.
• instance를 method 호출 시 생성한다면 여러 thread에서 접근할 때 문제가 되지 않도록 유의한다 (synchronized keyword 사용).

• instance의 수를 유일하게 제약함으로서 구현의 복잡도를 줄일 수 있는 경우에 사용한다.

• Java에서는 enum을 사용하여 구현하는 방법도 있다.

enum Singleton {
	INSTANCE;
	public void hello() {
		System.out.println("say hello!");
	}
}
// 아래와 같이 사용한다.
Singleton.INSTANCE.hello();

Prototype

• 객체의 복제 clone 를 통해서 새로운 객체를 만들어 낸다. 보통 아래와 같은 경우에 사용된다.
• 객체의 종류가 너무 많아서 이를 각각 class로 작성하기 어려운 경우.
• 동일한 class로 생성된 객체이지만 data에 따라서 서로 다른 동작을 할 수 있는 경우의 수가 많을 때 사용한다.
• class로 부터 직접 instance를 생성하기 어려운 경우.
• 이 부분은 객체 생성 과정 또는 내부의 state가 복잡하여 이를 복사해서 사용해야 되는 경우를 의미하는 것이다.
• framework를 특정 class에 의존하지 않게 만들고 싶은 경우.
• 미리 만들어진 원형 객체를 받아서 등록하고 이후에 등록된 객체를 복제하여 사용하는 것을 말한다.

• 복사를 위한 별도의 method를 정의하는 것도 가능하지만 Java의 경우 clone method를 override 할 수도 있다.

Builder

• 일련의 작업 (method로 표현)을 통해서 데이터 또는 객체를 구성한다.

• Client - Director - Builder로 역할이 나뉜다.
• Client는 Director에게 목적하는 데이터 또는 객체를 구성해 달라고 의뢰construct(BuilderI)한다.
• Director는 Builder의 method 만을 호출하여 데이터 또는 객체를 구성한다.
• Director는 builder의 구체적인 구현체를 모르며 Client가 의뢰한 대로 객체의 구성만 신경쓴다.
• 이는 의존성 주입(Dependency Injection)의 한 형태로 볼 수 있다.
• Client는 결과의 구성을 Director에게 위임하며 자신은 전혀 관여하지 않는다.
• 다만 Client는 최종적으로 구성된 결과를 Builder로 부터 직접 받는다.
• 이 때 사용되는 method는 반드시 interface로 정의되어 있어야 할 필요는 없다.

Structural Patterns

Bridge

• 상속을 기능, 구현의 두가지 계층으로 분리하여 수행한다. 구현이란 API와 같이 환경에 따라 구현체가 달라지는 부분을 의미하고 기능은 API를 이용해서 실제로 어플리케이션이 수행할 작업을 구현하는 부분을 의미한다.

• 기능 계층의 경우 구현 계층의 인스턴스를 사용한다 (예: new Painter(new LinuxFrameBuffer())).

• 위임을 통해서 기능과 구현 간의 느슨한 결합을 만든다.

• 구현 계층의 경우 직접 생성하여 사용하는 방식도 있지만 Abstract Factory pattern을 사용하는 경우도 있을 수 있다.

• 실질적인 구현 부분을 구현 계층에 위임한다는 측면에서 template method pattern과 유사하다 (template method의 경우 subclass에 위임).

• Adapter pattern과 비슷해 보이지만 다르다. Adapter pattern의 경우 동일한 기능을 수행하지만 인터페이스는 다른 두 객체를 결합하는데 사용된다.

• 예제: 화면에 그림을 그리는 라이브러리를 구성한다
• 구현 계층
• 기능 계층

Composite

• 재귀적인 구조를 표현하는 방법으로 그릇의 역할인 Composite와 내용물인 Leaf로 구성된다.
• Composite 내부에는 Leaf 또는 다른 Composite가 담길 수 있고 둘은 Component라는 interface를 통해서 동일시 된다.
• 예를 들어서 디렉토리 구조의 경우 Directory (Composite), File (Leaf), Entry (Component) 객체로 구성될 수 있다.

• 또는 여러 객체를 묶어서 하나로 취급(Grouping)할 수 있도록 해주는 방법도 여기에 해당된다.
• 예를 들어 High Order Component를 compose로 묶어서 하나의 HOC로 표현하는 것이 있겠다.

Decorator

• Decorator는 핵심이 되는 객체 (Component)에 기능을 추가하여 동일한 형태의 객체를 만들어내는 패턴이다.
• 중요한 포인트는 기능을 추가함에도 형태는 동일하게 만들어진다는 점이다. 즉, 기능의 추가 여부가 외부로 부터 숨겨진다.
• 이를 달리 말하면 decorator로 감싸더라도 내용물의 인터페이스가 그대로 노출된다고 표현할 수 있다 (투과적).
• 핵심 객체에 변경을 가하지 않고도 기능을 추가할 수 있는데 이는 요청이 핵심 객체로 위임되기 때문이다.
• 또한 기능 추가는 얼마든지 중첩될 수 있으며 동적으로 구성 가능하다.
• 상속도 decorator와 마찬가지로 기능을 추가하면서도 인터페이스를 그대로 유지(투과)할 수 있다. 하지만 위임과 달리 상속은 강한 결합이며 동적으로 변경할 수 없다.

• 핵심이 되는 객체는 인터페이스 또는 추상 객체로 정의될 수 있으며 후자의 경우는 Template Method와 유사한 형태가 된다.
• 단위 기능은 abstract method로 정의될 수 있고 핵심 객체 또는 Decorator에서 구현된다.

• 단, Template Method와 다른 점은 Decorator는 또 다른 객체를 감싸는 형태로 구현된다는 점이다.
• 예를 들어 문자열을 출력하는 StringDisplay concrete component와 문자열을 감싸서 경계선을 출력하는 Border decorator가 존재할 때 Border 객체는 new Border(new StringDisplay(contents)) 와 같이 생성될 수 있다. 이렇게 생성된 객체 또한 동일한 component로 취급될 수 있다.

• Java의 Reader 구현이 이에 대한 대표적인 예제이다.
• 예 1: new BufferedReader(new FileReader(filePath))
• 예 2: new LineNumberReader(new BufferedReader(new FileReader(filePath)))

Facade

• Facade (파사드) 패턴은 시스템을 구성하는 다양한 역할을 숨기고 단순화된 창구로 제공하는 방식이다.
• 보통 시스템의 구성이 고정되어있어서 사용자가 시스템을 구성하는 객체들을 특정한 방식으로만 사용하게 될 때 취할 수 있는 방법이다.
• Facade 객체에는 시스템을 구성하기 위해 필요한 모든 로직을 담고 있다.
• 달리 말하면 시스템을 구성하는 방법을 코드로 표현한 것이다.
• 매번 사용자가 역할 하나를 수행하기 위해서 시스템 내부의 객체들을 구성하는 과정을 반복해서 수행하지 않게 만들어 준다.
• 또한 사용자가 실수로 내부의 객체를 잘못 구성하는 경우, 객체를 초기화하기 위해 호출해야 하는 특정한 루틴을 빼먹는 경우를 방지할 수 있다.

• Builder랑 비슷해 보일 수는 있는데 Builder는 부품 생성과 이를 통해 완성품을 구성하는 역할을 위임하는 것이 중점이라면 Facade는 내부에 어떤 부품이 있는지는 숨기고 사용자에게는 단순한 제품의 외형만을 제시한다는 점에서 다르다.

• Adapter와도 비슷해보일 수 있지만 Adapter는 구현체를 수정하지 않고도 사용자가 필요로하는 인터페이스를 제공하는게 목적이라면 Facade는 인터페이스의 수를 줄이고 단순화하는데에 중점을 둔다.

Flyweight

• 메모리 소비를 줄이기 위해 인스턴스를 공유하는 방법이다.
• Factory Method 패턴을 이용하여 인스턴스 생성을 통제하고 변하지 않는 정보 (intrinsic)를 기준으로 인스턴스를 생성하고 공유한다.
• 공유되는 인스턴스를 관리하고 저장하는데 추가적인 자원이 들어간다.
• 예를 들어서 특정 정보를 기준으로 이미 해당되는 인스턴스가 생성되었는지 체크하고 없으면 생성하는데 시간을 소비하며 생성된 인스턴스는 메모리 상에서 해제되지 않고 유지되어야 하므로 메모리를 소비한다.
• 물론 cache나 weak map 등을 이용하여 인스턴스의 수를 일정하게 관리할 수는 있지만 이것은 최적화의 영역이다.

• Java String에서 제공하는 intern method가 대표적인 예이다.

• 어떤 면에서는 Singleton과 비슷한데 Singleton은 유일한 객체를 만들고자 한다는 점에서 Flyweight는 특정 정보에 대해서는 유일하지만 정보의 개수만큼 인스턴스를 유지하고 관리한다는 측면에서 차이가 있다.

Proxy

• 대상 객체를 대리하여 작업을 수행하는 방법이다.
• 대상 객체의 생성을 지연시키고 일부 작업을 생성 전에 스스로 & 미리 대리하여 수행할 수 있다.
• 대리자가 수행할 수 없는 작업을 요청한 경우 대리자는 실제 대상 객체를 생성하고 작업을 위임한다.
• 실제 대상 객체가 생성된 후 일부 작업의 경우 대리자가 수행 + 대상 객체에 반영하도록 작업을 위임하게 된다.
• 대상 객체의 생성 및 초기화 과정에서 많은 양의 자원이 사용될 경우 이를 지연 시킴으로써 사전에 일부 작업을 미리 완료하거나 필요하지 않다면 생성을 하지 않는 방식으로 최적화할 수 있다.

• 대상이 되는 실제 객체 (RealSubject)와 대리자 (Proxy)는 동일한 인터페이스 (Subject)를 갖는다.
• Decorator와 마찬가지로 투과적인 특성을 가진다.

• 대리자의 유형은 아래와 같다.
• Virtual Proxy (가상 대리자)
• 실제로 인스턴스가 필요한 시점에 생성한다.
• Remote Proxy (원격 대리자)
• 원격에 존재하는 객체를 마치 로컬에 있는 것처럼 호출한다.
• Access Proxy (보호 대리자)
• 대상 객체에 접근 가능한 사용자만 접근할 수 있도록 제한한다.

Behavioral Patterns

Template Method

• super class에서 뼈대를 결정하고 child class에서 구체적인 동작을 결정한다.

• 전체 작업을 몇개의 단위 작업으로 나누고 각각을 interface 화 한다.
• 예: display() = open() + print() + close()

• super class에는 algorithm 또는 logic이 존재하고 child class에는 단위 작업의 구체적인 implementation이 있다.

• Abstract class를 사용하는 대표적인 예이다.

Strategy

• 특정한 context 내에서 사용하는 알고리즘을 객체로 분리(위임)하여 교환 가능하게 한다.

• 상속(예: Template Method)으로도 이런 문제를 해결할 수 있지만 상속은 강한 결합이며 위임은 약한 결합이고 쉽게 수정 가능하다.

Visitor

• Visitor는 객체의 구조와 처리를 분리하기 위해서 사용하는 방법이다.
• 객체의 구조는 Composite 패턴을 구조에 대한 처리는 Visitor 패턴을 사용하여 구현된다.
• 구조를 담당하는 객체는 Element, 처리를 담당하는 객체는 Visitor로 불린다.

• Element와 Visitor는 각각 accept, visit method를 통해서 강하게 결합된다.
• Element::accept method에서는 특정 객체에 대한 처리를 Visitor로 위임하는 작업을 수행한다.
• 예: File::accept(Visitor)의 경우 EntryVisitor::visit(File)을 호출한다. 이는 명시적으로 File에 대한 처리를 EntryVisitor에게 위임하는 것이다.
• Visitor::visit method에서는 Element의 구체적인 구현 객체 별로 서로 다른 처리를 method overloading을 통해서 구현한다.
• 예: EntryVisitor는 visit(File), visit(Directory)를 각각 구현해야 한다.
• 당연하겠지만 Visitor가 처리를 하기 위해서 Element가 충분한 정보를 제공해줄 수 있는 인터페이스를 가지고 있어야 한다.
• 예를 들면 Directory는 처리를 위해서 자신이 가진 Entry의 목록을 제공해주어야 한다.
• 이런 특성으로 인해 객체의 구조에 새로운 타입이 추가된다면 각각의 accept, visit method를 추가해주어야 한다.
• 이런 형식으로 상호간에 호출이 발생하는 패턴을 double dispatch라고 한다.

• Visitor 패턴은 OCP (Open-Closed Principle)의 대표적인 예이다.
• 객체는 확장에는 열려있되 수정에는 닫혀 있어야 한다.
• 새로운 처리 방식이 필요할 떄는 Visitor를 새로 구현함으로서 기능을 확장할 수 있다.
• 반면 기존 클래스는 이에 따르는 수정이 필요 없게 된다.
• 다만 이는 처리 기능의 확장에만 해당되며 데이터 구조인 Element 객체의 확장에는 적용되지 않는다.
• 데이터 구조가 변경되면 그에 따라 새로운 ConcreteElement가 추가되므로 Visitor의 인터페이스가 변경되고 연쇄적으로 ConcreteVisitor의 수정이 발생하게 된다.
• 다만 일반적으로 데이터 구조의 변경보다는 기능의 추가가 더 빈번하게 발생하므로 이런 전략이 실용적이라고 볼 수 있다.

Q. accept method는 꼭 필요한가? C++의 variant 구현을 보면 accept method를 활용하지 않고도 Visitor 패턴을 구현한 것을 볼 수 있다. 이는 C++에서 제공하는 SFINAE (Substitution Failure Is Not An Error) 기법을 이용한 것으로 특정한 타입에 대한 처리를 위임하는 것을 언어의 기능으로 구현한 것일 뿐이다. Java에서도 reflection API을 이용하면 유사하게 구현 가능하다. 위임의 방식이 단순히 Visitor를 호출하는 것 뿐이라면 이렇게 하더라도 문제는 없을 것이다 (물론 reflection API를 쓰면 성능 문제는 고려해야 겠지만). 하지만 이와 같은 방식은 처리를 위임한다는 사실을 묵시적(implicit)으로 변경해버린다. 또한 일반적이지는 않지만 객체가 위임하는 방식을 다르게 결정할 수 있는 가능성도 제거해버린다. 예를들면 어떤 객체는 Visitor에게 처리를 여러번 하도록 요청할 수도 있다. 결론적으로 accept method는 Element 객체가 어떻게 Visitor에게 처리를 위임할 것인가를 결정하는 통로이므로 필요하다.

Chain Of Responsibility

• 특정한 요청에 대한 처리가 고정되어있지 않은 경우 여러 개의 처리자 (Handler)를 엮어서 요청에 대한 처리를 위임하는 방법이다.
• 이 패턴은 마치 LinkedList 처럼 여러 개의 Handler 순차적으로 연결하는 방식으로 구성되며 이 중 하나의 Handler가 요청을 처리하게 된다.
• 특정한 Handler는 요청 처리 여부를 판단하여 (1) 가능한 경우 요청을 처리하고 결과를 돌려주거나 (2) 다음 Handler로 요청의 처리를 위임한다.
• 요청을 어떤 처리자가 처리해야 할지 숨기게 되므로 요청자와 처리자 간의 관계를 느슨하게 만든다.
• 이 패턴을 사용하지 않는다면 중앙에서 요청의 형태에 따라 처리자를 매칭하는 방식을 사용해야 하며 이런 방식은 요청자의 처리자의 결합을 더 강하게 만든다.

• Decorator 패턴과 같이 사용될 수 있다.
• 예를 들어 특정 Handler는 요청에 대한 일부 항목을 처리한 뒤 다음 Handler에게 나머지 처리를 위임할 수 있다.

• 대표적인 구현의 예로 middleware가 있다.
• Middleware는 특정한 요청에 대한 독립적인 처리 기능을 제공하는 처리자로 특정한 순서에 따라 결합될 수 있다.

Mediator

• 다수의 객체로 구성된 시스템에서 여러 객체 간의 메시지 전송을 단순화하기 위해서 사용하는 방법이다.
• 객체의 수가 많아질 수록 상호간에 메시지를 주고 받는 관계의 수는 기하급수적으로 증가할 수 있다.
• 여러 객체에 걸쳐있는 상태를 기준으로 특정 객체에게 지시를 내려야 한다면 이를 중앙에서 제어할 수 있는 중재자가 필요하다.
• 만일 중재자가 없다면 지시와 관련된 개별 객체 마다 변경 사항을 추적하는 동일한 상태와 구현을 작성해야 한다.
• 다른 객체에게 지시 (메시지 전송)하는 작업을 중재자에게 위임하고 개별 객체는 자신의 역할에만 충실하게 만들 수 있다.
• 어플리케이션에 의존성이 높은 비즈니스 로직을 중재자라는 형태로 분리해내는 방식으로 사용될 수 있다.

• 개별 객체는 중재자에게 메시지를 보고하며 중재자는 이를 바탕으로 특정 객체에게 지시를 내린다.
• 개별 객체가 중재자에게 보고하는 방식은 Observer 패턴을 이용할 수 있다.
• 중재자는 이를 바탕으로 특정 객체에 지시를 내릴 수 있다. 지시 대상이 되는 객체와의 결합에는 다른 패턴을 활용할 수도 있겠다.
• 예를 들어 중재자가 특정 객체에 지시를 내리는 것 조차도 Observer 패턴을 적용할 수 있다.

Observer

• 관찰 대상 객체 (Subject)에 관찰자 (Observer)를 등록함으로서 상태 변화를 감지하는 방법이다.
• Observer라는 이름과 달리 관찰자는 관찰 대상 객체가 주는 정보를 수동적으로 받아들이기만 한다.
• 관찰 대상 객체는 관찰자의 정의된 인터페이스를 통해서 상태가 변경되었을 때 자기 자신 또는 객체의 정보를 통지한다.
• 하나의 관찰 대상 객체에 대해서 관찰자는 하나 이상일 수 있다.

Memento

• 특정한 객체의 상태를 관리하고 필요에 따라 복원할 필요가 있을 때 사용하는 방법이다.
• 상태를 관리하는 역할인 관리인 Caretaker, 상태에 대한 snapshot을 생성하는 역할인 작성자 Originator가 존재한다.
• Memento 패턴은 관리인이라는 역할을 통해 상태를 관리하는 방식을 대상 객체로 부터 분리해내는 방법이라고 볼 수 있다.
• 작성자는 관리인에 요청에 따라 (1) 특정한 객체의 상태 Memento를 생성하거나 (2) Memento를 사용하여 상태를 복원할 수 있다.
• 객체의 상태 Memento는 관리인, 작성자 각각에 대해서 서로 다른 두가지 인터페이스를 노출한다.
• 관리인에게는 좁은 narrow 인터페이스를 노출한다. 관리인에게 Memento는 블랙 박스이며 내부를 수정할 수 없고 지정된 상태 값만 제공받을 수 있다.
• 작성자에게는 넓은 wide 인터페이스를 노출한다. 작성자는 Memento를 생성하거나 내부 상태를 수정할 수 있다.

State

• 개별 상태에 대한 객체를 만들고 각 상태 객체에 특정 상태에서의 처리 역할을 맡기는 방법이다.
• 문제를 분할 (divide and conquer) 하는 방식 중 하나로 시스템의 상태에 따라 문제를 분할하여 더 작은 규모로 만든다.
• 만일 상태 별로 객체를 생성하지 않는다면 하나의 객체 내부에서 상태 값에 따라서 분기문을 작성해야 한다.
• 이런 방식은 실수를 할 가능성이 높고 잘못이 발생했을 때 인지하기 어렵게 된다.
• 상태 별로 객체를 분리하게 되면 특정 상태에 대해 처리해야 될 항목이 분명하게 인터페이스로 존재하므로 빼먹고 구현하지 않으면 오류가 발생해서 인지하기 쉽다.

• 상태를 전환하는 역할은 상태를 관리하는 객체인 Context가 할 수도 있고 개별 상태 객체 State에 위임할 수도 있다.
• Context가 할 경우
• Mediator 패턴을 사용하여 각 상태 객체는 Context에 변경을 보고하고 Context는 이에 따라서 상태를 변환하고 지시를 내릴 수 있다.
• 이를 위해서 Context는 모든 State 객체를 알아야 한다.
• State가 할 경우
• State가 직접 상태를 확인하여 Context에게 상태를 변경하라고 메시지를 보내야 한다.
• Context는 초기 상태에 해당되는 State만 알면 되지만 각 State 객체는 서로가 서로를 알아야 한다.

Q. 상태 변경 관리는 누가 하는게 좋을까? 결론만 말하자면 Context가 하는게 더 유리해 보인다. State가 상태 변경을 관리한다면 개별 State의 역할에 충실할 수 없고 서로 다른 State에 대해서 알아야될 필요가 있다. 또한 상태 변경은 일반적으로 단일한 상태값 보다는 다양한 상태값들을 기반으로 이루어지는 경우가 많다. 이런 상황에서 개별 State 객체에서 여러가지 정보를 다루는 것은 비효율적이며 중복된 코드를 만들 가능성이 높다. 차라리 Mediator 패턴을 사용하여 Context에서 그런 비즈니스 로직을 모아두는 것이 바람직할 것으로 생각된다.

Command

• ‘작업’을 객체화하여 관리하고 필요 시 지정된 순서에 따라 실행할 수 있도록 하는 방법.
• 객체화된 작업을 명령 (Command) 또는 사건 (Event)라고 부른다.
• 객체에게 메시지를 전달하는 메소드 호출은 객체가 아니기 때문에 기록하거나 관리될 수 없다.
• 반면 명령 또는 사건의 경우 객체의 형태를 가지므로 시간과 묶어서 저장하는 등의 관리가 가능하다.

• 명령의 인터페이스 (API), 보유하는 정보는 정해져있지 않으며 구현하는 클래스에 따라 결정된다.

• 명령이 수행하는 실제 작업은 수신자 (Recever)에 위임된다.

Interpreter

• 해결해야될 문제를 미니 언어로 표현하고 그 표현을 해석하여 실행함으로서 프로그램의 수정 없이 다양한 상황에 대응할 수 있도록 하는 방법.
• 일반적으로는 문제가 변경되거나 새로운 요구사항이 추가된 경우 프로그램을 수정한다.
• 해결해야될 문제를 미니 언어로 표현하고 그것을 해석하여 실행하는 프로그램을 만들면 미니 언어로 작성된 미니 프로그램을 수정하여 변경 사항에 대응할 수 있다.

• 미니 프로그램 (미니 언어로 작성) → 미니 언어 인터프리터 → 프로그래밍 언어 실행 환경 의 3계층으로 구성된다.

• 미니 언어는 Backus-Naur Form (BNF)와 같은 형식으로 정의될 수 있다.
• BNF로 정의된 표현 중 표현의 정의가 다른 표현으로 전개 (확장)되는 표현은 non-terminal, 전개되지 않는 표현은 terminal expression 이라고 부른다.

• 정의된 미니언어를 객체로 구조화할 수 있으며 이 때 BNF에 정의된 항목과 대응되는 객체를 노드 (Node)라고 부른다.
• 이렇게 생성된 노드를 탐색하여 실행함으로서 목적하는 문제를 해결할 수 있다.

• Command 패턴과 결합하여 다양한 순서로 조합된 작업을 실행하는 해석기를 만들 수 있다.

• 또는 dependency injection과 같이 프로그램을 구성하는 객체간의 관계를 맺는 방식을 미니 언어로 기술하여 구성할 수 있다.