[Java] GOF 디자인패턴 용어 정리

생성패턴

Abstract Factory Pattern(추상 팩터리 패턴)

- 패턴 설명 : 다양한 구성요소(Product)별로 '객체의 집합'(Factory)을 생성할 때 유용. 서로 관련있는 객체들을 묶어 팩터리 클래스로 만든 후 팩터리를 조건에 따라 생성하도록 다시 팩터리를 만들어서 객체를 생성하는 패턴

- Abstract Factory : (예) 컴퓨터 생성 - 모니터 생성, 본체 생성 

- Concrete Factory : (예) 삼성컴퓨터 생성 - 삼성모니터생성, 삼성본체생성 / LG컴퓨터 생성 - LG모니터생성, LG본체생성

- Abstract Product : (예) 모니터 / 본체

- Concrete Product : (예) 삼성모니터, LG모니터 / 삼성본체, LG본체

Builder Pattern(빌더 패턴)

- 패턴 설명 : 복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여 서로 다른 표현이라도 이를 생성할 수 있는 동일한 구축 공정을 제공할 수 있도록 하는 패턴

- Builder : 빌더 인터페이스

- Concrete Builder : 빌더 인터페이스 구현체. 부품을 합성하는 방식에 따라 여러 구현체를 만든다.

- Director : Builder를 사용해 객체를 생성

- Product : Director가 Builder로 만들어낸 결과물

- return this; : return this를 사용하면, .으로 체이닝을 이어갈 수 있음! (마치 람다의 스트림처럼 보인다)

public class Student {
    private final int year;
    private final int month;
    private final int day;
    private final int level;
    private final int ranking;
    private final String name;
    private final int age;

    public static class Builder {
        // Required parameters(필수 인자)
        private final int year;
        private final int month;
        private final int day;

        // Optional parameters - initialized to default values(선택적 인자는 기본값으로 초기화)
        private final int level;
        private final int ranking;
        private final String name;
        private final int age;

        public Builder(int year, int month, int day) {
            this.year = year;
            this.month = month;
            this.day = day;
        }

        public Builder level(int level) {
            this.level = level;
            return this;    // 이렇게 하면 .으로 체이닝 가능
        }
        public Builder ranking(int ranking) {
            this.ranking = ranking;
            return this;
        }
        public Builder name(String name) {
            this.name = name;
            return this;
        }
        public Builder age(int age) {
            this.age = age;
            return this;
        }
        public Student build() {
            return new Student(this);
        }
    }

    private Student(Builder builder) {
        year    = builder.year;
        month   = builder.month;
        day     = builder.day;
        level   = builder.level;
        ranking = builder.ranking;
        name    = builder.name;
        age     = builder.age;
    }
}

Student jamie = new Student
    .Builder(2020, 2, 5)    // 필수값 입력
    .level(2)
    .ranking(51)
    .name("jamie")          // 옵션값인 Age는 입력 안함
    .build();               // build()가 객체를 생성하고 돌려줌.

Factory Method Pattern(팩터리 메서드 패턴)

- 패턴 설명 : 상위 클래스(Abstract Creator)에 알려지지 않은 Concrete Product를 생성하는 패턴, Concrete Creator가 Concrete Product를 결정

- 특징 : Template Method Pattern의 생성 버전

- Abstract Creator : Product Interface에 담길 객체를 생성하는 주체가되는 추상 클래스. Template Method Pattern을 이용하여 create() 등의 Factory Method의 골격을 짜고(Product를 생성하는 메서드), 내용을 abstract method로 생성해둠

- Concrete Creator : Abstract Creator의 추상 메서드를 Concrete Product를 이용할 수 있도록 구현

- Product Interface : Creator에 의해 추가될 객체의 인터페이스

- Concrete Product : Product Interface를 구현한 클래스, Concrete Creator에 의해 구현 예정

Prototype Pattern(프로토타입 패턴)

- 패턴 설명 : 런타임에 또 다른 객체를 생성하는 것. 생성할 객체들의 타입은 Prototype의 인스턴스로부터 결정, 인스턴스는 새 객체를 생성하기 위해 자기 자신을 복제(clone - 깊은 복사), 생성 비용이 비쌀 경우 유용함

- Cloneable : Object의 clone() Method를 사용하는 것을 명시하는 Interface

- Prototype : clone() 선언 및 구현, clone()을 선언하기 위해선 Cloneable을 구현해야 함

- Sub Prototype : Prototype을 상속

- 얕은 복사 : =로 대입해서 넣었을 때, 참조 타입의 경우 동일 주소값을 가져가게 됨

- 깊은 복사 : clone()을 이용하여 가지고 있는 값을 복사, 같은 값이지만 다른 주소값을 가져가게 됨

    - 단, clone을 이용하는 경우 객체 내의 기본형만 깊은 복사가 되고, 참조형은 얕은 복사가 되게 되는데 이 부분은 신경써줘야 함

Singleton Pattern(싱글턴 패턴)

- 패턴 설명 : 인스턴스가 프로그램 내에서 오직 하나만 생성되는 것을 보장하고, 프로그램 어디에서든 해당 인스턴스에 접근할 수 있도록 하는 패턴

- Singleton : (사전적 의미) 하나의 개체

- private 생성자 : 외부에서의 객체 생성을 막기 위해 생성자를 private으로 해 둠, 상속 또한 불가능해짐

- SingletonClass.getInstance() : 외부에서 객체를 받아오기 위한 Static 클래스

- Static Class와 Singleton Pattern의 차이 - Singleton Pattern의 경우 처음에 객체 생성을 하지 않고, 필요시 생성할 수 있음

구조패턴

Adapter Pattern(어댑터 패턴)

- 패턴 설명 : Adaptee 클래스의 인터페이스를 사용자가 기대하는 인터페이스로 변환시켜주는 패턴

- Adapter Interface (어댑터 인터페이스) : 사용자가 기대하는 인터페이스

- Concrete Adapter (구현한 어댑터) : Adapter Interface와 Adaptee를 이어주는 부분을 실제 구현한 클래스

- Adaptee(어댑티) : 사용자가 실제로 사용하려는 클래스로, 사용자가 기대하는 인터페이스와 차이가 있음

Bridge Pattern(브릿지 패턴)

- 패턴 설명 : 구현부(Implementor)에서 추상층(Abstraction)을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴

- 특징 : 어댑터 패턴과 흡사함, 하지만 사용 목적의 차이가 있음

    - 어댑터 패턴 : 기대하는 인터페이스와 클래스가 다를 경우, 가운데 어댑터를 두어 맞춰주는 것(리팩터링..?)

    - 브릿지 패턴 : 추상과 구현 분리, 변경해도 서로 영향 없음(확장성 중점)

- Abstraction : 기능 계층의 최상위 클래스. Implementor를 생성자로 받아서 변수로 가지고 있음. Implementor에 위임(Delegation)할 부분을 모두 구현메서드로 가지고 있음. 그 외는 추상 메서드.

- Refined Abstraction : Abstraction를 상속받아 추상메서드를 구현한 클래스.

- Implementor : 구현 클래스를 위한 인터페이스이자 Abstraction의 기능을 구현하기 위한 인터페이스

- Concrete Implementor : Implementor를 구현. 즉, 실제 기능 구현.

Composite Pattern(컴포짓 패턴)

- 패턴 설명 : 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 함

- Component : 모든 표현할 요소들의 추상적인 인터페이스

- Leaf : Component을 구현한 구현 클래스

- Composite : Component를 구현한 구현 클래스. Component들을 변수로 가지고 있음, Component 요소를 관리하기 위한 메서드들을 추가로 가지고 있음 - Leaf와 Composite 모두 관리가 될 것이고 이 부분이 단일 객체와 복합 객체를 모두 동일하게 다루도록 한 것!

Decorator Pattern(데코레이터 패턴)

- 패턴 설명 : 주어진 상황 및 용도에 따라 어떤 객체에 책임(from Decorator)을 덧붙이는 패턴. 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있음

- Component : Concrete Component와 Decorator에서 공통으로 사용될 인터페이스 정의, 클라이언트는 Component를 통해 실제 객체 사용

- Concrete Component : 기본 기능을 구현한 클래스

- Decorator : Concrete Decorator들의 공통 인터페이스를 정의한 추상 클래스. Component를 변수로 가지고 있음 - 생성자에서 받음

- Concrete Decorator : Decorator의 하위 클래스로, Concrete Component에 추가되는 개별적 기능 정의

Facade Pattern(퍼사드 패턴)

- 패턴 설명 : 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 간략화된 인터페이스를 제공하는 객체

- 어댑터 패턴 VS 퍼사드 패턴

    - 어댑터 패턴 : 클라이언트가 원하는 인터페이스에 맞춰주는 패턴

    - 퍼사드 패턴 : 클라이언트가 사용하기 복잡한 인터페이스를 쉽고 단순하게 만들어주는 패턴

- Facade : Package의 기능을 간략화된 인터페이스를 통해 제공하는 Class

- Package : 소프트웨어 API / 라이브러리의 집합, Facade Class를 통해 접근됨

Flyweight Pattern(플라이웨이트 패턴)

- 패턴 설명 : 동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 소프트웨어 디자인 패턴. ex) Java의 쓰레드 풀, 객체 재사용 풀 등. 이미 존재하는 비슷한 종류의 객체를 저장하여 재사용을 시도하고 일치하는 객체가 발견되지 않으면 새로운 객체를 만듦. 

    - 중복 생성 가능성이 높은 -> 동일한 자원이 자주 사용될 가능성이 매우 높은 구현 객체. 이런 자원은 공통 자원 형태로 관리하고 있다가 요청이 있을 때 제공해 주는 편이 좋음

    -자원 생성 비용이 크지만, 사용 빈도가 낮은 구현 객체. 요청이 있을 때 생성해서 제공해주는 것이 좋음

- Flyweight : 관리해야 할 자원에 대한 생성 및 제공을 담당

- Concrete Flyweight : Flyweight 구현 객체

- Flyweight Factory :Concrete Flyweight 객체의 자원 생성을 담당하는 역할. 역할이 크지 않은 경우 Concrete Flyweight 객체 하나로 생성+관리하기도 함(즉, 사용하지 않을 수 있음)

Proxy Pattern(프록시 패턴)

- 패턴 설명 : 실제 객체를 대신하는 프록시 객체를 사용해서 실제 객체의 생성이나 접근 등을 제어할 수 있도록 해주는 패턴. 단, 흐름 제어만 할 뿐, 결과값을 조작/변경해서는 안 됨

- 데코레이터 패턴 vs 프록시 패턴

    - 데코레이터 패턴 : 기존 객체의 기능을 확장하는데 초점

    - 프록시 패턴 : 실제 객체에 대한 접근을 제어하는데 초점

- Subject : 실제 사용할 클래스 중, 프록시할 기능의 시그니처

- Real Subject : Subject 인터페이스를 구현한 실제 Subject

- Proxy : Subject를 동일하게 구현하여 실제 사용할 클래스(RealSubject)와 동일한 시그니처의 메서드를 가짐. RealSubject를 가리키는 변수를 가짐(조합). RealSubject의 같은 이름을 가진 메서드를 호출 후 그 값을 클라이언트에게 돌려줌, 호출 전/후로 별도의 로직 호출 가능(단, 값을 조작할 순 없음)

행위 패턴

Chain of Responsibility(책임 연쇄 패턴)

- 패턴 설명 : 명령 객체와 일련의 처리 객체를 포함하는 패턴. 각각의 처리 객체는 명령 객체를 처리할 수 있는 연산의 집합이고, 체인 안의 처리 객체가 핸들할 수 없는 명령은 다음 처리 객체로 넘겨짐. 이 작동방식은 새로운 처리 객체부터 체인의 끝까지 다시 반복. 이 패턴은 결합을 느슨하게 하기 위해 고안되었으며 가장 좋은 프로그래밍 사례로 꼽힘

    - 각각의 처리 객체에서 처리할 수 있으면 처리하고, 처리할 수 없으면 다음 처리 객체로 넘김, 처리 객체들은 서로 사슬처럼 연결되어 있어 먼저 처리하는 객체에서 처리할 수 없으면 다음에 연결된 처리객체로 명령을 넘김.(링크드 리스트와 비슷)

- Handler : 요청을 수신하고 처리 객체들의 집합에 전달하는 클래스 - 처음에 넘길 실제 클래스만 알고 있음

- Concrete Handler : Handler를 상속, 요청을 처리하는 실제 클래스 - 다음 넘길 실제 클래스를 알고 있음

Command Pattern(커맨드 패턴)

- 패턴 설명 : 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴.

- Command : 실행 기능에 대한 인터페이스, 실행될 기능을 execute 메서드로 선언.

- Concrete Command : Command 인터페이스(execute)를 구현. Recevier 객체를 가지고 있으며, execute 메서드는 Receiver 객체의 메서드를 호출. Invoker 객체에 전달되어 명령을 실행하게 됨.

- Invoker(발동자) : 기능 실행을 요청하는 호출자 클래스. 필요에 따라 기능 실행에 대한 기록을 남길 수도 있음. 한 Invoker 객체에 다수의 Command 객체가 전달될 수 있음.

- Receiver(수신자) : ConcreteCommand에서 execute 메서드를 구현할 때 필요한 클래스. ConcreteCommand의 기능을 실행하기 위해 사용하는 클래스로, Command 객체에서 호출시 자신에게 정의된 메서드를 수행.

- Client : Invoker 객체와 하나 이상의 Command 객체를 보유. 어느 시점에서 어떤 명령을 수행할지를 결정. 명령을 수행하려면, 클라이언트 객체는 발동자 객체로 커맨드 객체를 전달

Interpreter Pattern(해석자 패턴)

- 패턴 설명 : 문법 규칙을 클래스화 한 구조, 일련의 규칙으로 정의된 언어를 해석하는 패턴

- AbstractExpression : 표현 인터페이스

- TerminalExpression : 주요 해석기(main interpreter)로써 동작하도록 정의

- AndExpression/OrExpression : 복합적(conbinational) 표현을 생성하기 위해 사용

Iterator Pattern(반복자 패턴)

- 패턴 설명 : 객체 지향 프로그래밍에서 반복자를 사용하여 컨테이너를 가로지르며 컨테이너의 요소들에 접근하는 디자인 패턴. 컨테이너로부터 알고리즘을 분리(일부의 경우 알고리즘이 컨테이너에 특화되어 있으므로 분리가 불가). 기반이 되는 표현을 노출시키지 않고 연속적으로 객체 요소에 접근하는 방법을 제공하는 것

- Aggregate : 여러 요소들로 이루어진 집합체

- Concrete Aggregate : Aggregate 인터페이스를 구현

- Iterator : 집합체의 요소들을 순서대로 검색하기 위한 인터페이스

- Concrete Iterator : Iterator 인터페이스를 구현

Mediator Pattern(중재자 패턴)

- 패턴 설명 : 어떻게 객체들의 집합이 상호작용하는지를 함축해놓은 객체를 정의(중재자), 객체 간 통신은 중재자 객체 안에 함축. 객체들은 더 이상 다른 객체와 서로 직접 통신하지 않으며 대신 중재자를 통해 통신 -> 통신 객체 간 의존성을 줄일 수 있으므로 결합도를 감소시킴

- Mediator : 실제 중재자 구현 로직에 대한 인터페이스. 중재자의 서비스를 받기 위한 클라이언트(Colleague)를 등록, 실행하는 API 시그니처가 정의

- Concrete Mediator : Mediator 구현부 구현한 클래스

- Colleague : 중재자에 의해 서비스를 받기 위한 인터페이스

- Concrete Colleague : Colleague 구현부 구현한 클래스

Memento Pattern(메멘토 패턴)

- 패턴 설명 : 객체를 이전 상태로 되돌릴 수 있는 기능을 제공하는 패턴

- 특징 : Memento와 Originator는 같은 패키지에 존재(CareTaker는 다른 패키지) Memento 생성자 및 메서드의 접근제한자는 Protected(CareTaker에서 접근 불가)

- CareTaker : Memento를 관리하는 관리자 역할

- Memento : Originator의 상태를 저장하는 객체

- Originator : 내부 상태를 보유하고 있는 일부 객체

- 진행 (CareTaker는 Originator에 대해 무언가를 하지만 변경에 대한 실행 취소를 하기를 원하는 상태)

    - CareTaker는 먼저 Originator에게 Memento 객체를 요청

    - 그 뒤 예정된 일련의 명령을 수행

    - 명령 이전의 상태로 되돌리기 위해 Memento 객체를 Originator에 반환

    - Memento 객체 자신은 Opaque data type(해당 데이터 타입의 내부 정보가 외부 인터페이스로 모두 노출되지 않은 데이터 타입)

Observer Pattern(관찰자 패턴)

- 패턴 설명 : 객체(Subject)의 변화를 관찰하는 관찰자(Observer)의 목록을 객체(Subject)에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체(Subject)가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴, 특정 객체에 의존하지 않으면서 상태의 변경을 관련된 객체들에게 통지하는 것이 가능

- Observer : notify 추상 메서드를 정의. notify는 관찰 대상이 발행한 메시지 이외에, 옵서버 자신이 생성한 인자값을 전달할 수도 있음

- Concrete Observer : nofity 메서드를 구현 - 이벤트 발생시 Subject에서 콜백을 받음

- Subject : 관찰 대상인 객체, 이벤트를 발생시키는 주체라는 의미에서 Subject. 1개 이상의 Observer 목록을 가지고 있음, 이벤트 발생시 해당 Observer에게 notify를 줌(notifyObservers). 보통 등록(registerObserver), 제거(unregisterObserver) 메서드가 있음. 그 외에도 작동 중지, 재개 등의 메서드들을 가지고 있을 수도 있음

State Pattern(상태 패턴)

- 패턴 설명 : 객체가 특정 상태에 따라 행위를 달리하는 상황에서, 자신이 직접 상태를 체크하여 상태에 따라 행위를 호출하지 않고, 상태를 객체화 하여 상태가 행동을 할 수 있도록 위임하는 패턴.

- State : 객체의 특정 상태가 할 수 있는 행위 인터페이스

- Concrete State : State를 구현한 특정 상태 구현 클래스

Strategy Pattern(전략 패턴)

- 패턴 설명 : 객체가 할 수 있는 행위들 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴

- Strategy Interface(전략 인터페이스) : 여러가지 관련 알고리즘을 하나로 추상화하여, 도출한 인터페이스

- Concrete Strategy(구현한 전략) : 여러가지 관련 알고리즘을 각각 구현한 클래스들

- Delegate(위임) : 구현 해야하는 기능을 구현된 다른 클래스에게 맡겨서, 마치 내가 구현한 것처럼 기능을 실행하는 것을 지칭

Template Method Pattern(템플릿 메서드 패턴)

- 패턴 설명 : 알고리즘의 뼈대를 정의하는 행위 디자인 패턴. Template Method를 구현해두고, 해당 구조의 상세 기능(메서드)는 구현 클래스에서 구현함. 구현하려는 알고리즘이 일정한 프로세스를 가지고 있고, 알고리즘 구현 내용이 달라질 수 있을 경우 사용

- Template Method : 알고리즘의 뼈대를 정의하고 있는 구현 메서드. 뼈대를 추상 메서드로 구현해두고 있음

- Abstract Class : 알고리즘의 뼈대, 즉 Template Method를 정의. 상세 기능(구조)는 추상 메서드로 정의해둠

- Concrete Class : Abstract Class에서 구현하지 않은 상세 기능을 구현. Template Method는 오버라이딩하지 않음

Visitor Pattern(방문자 패턴)

- 패턴 설명 : 알고리즘을 객체 구조에서 분리시키는 디자인 패턴. 이렇게 분리를 하면 구조를 수정하지 않고도 실질적으로 새로운 동작을 기존의 객체 구조에 추가할 수 있게 된다. 개방-폐쇄 원칙을 적용하는 방법의 하나.

    - 사용시 ConcreteVisitable.accept(new ConcreteVisiotr); 같은 느낌으로 호출하면, concreteVisitable의 

- 특징 : composite 패턴과 조금 유사함

- Visitor Interface : Visitable을 방문 - visit(Visitable), Concrete Visitable을 해당 Interface나 구현한 Concrete Visitor가 알아야, 다른 행동을 해줄 수 있는 듯

- Concrete Visitor : Visitor Interface 구현 - 알고리즘. 새로운 동작!

- Visitable Interface : Visitor를 받아줌 - accept(Visitor)

- Concrete Visitable : Visitable Interface 구현, 보통 Visitor 클래스에 자기 자신을 던져줌 (visitor.visit(this)) - 위임