[Design Pattern] GoF 디자인 패턴 개념 간단 정리

Iterator

데이터들을 가져오는 방법은 Aggregator(혹은 Container. 동일한 형태의 데이터를 여러 개 지닌 것)의 종류에 따라 모두 다르기 때문에, 이를 통일된 방법으로 가져오도록 돕는 패턴.

다양한 형태의 Aggregator의 데이터에 접근할 때에 표준화 된 공통API.

따라서 한편으로는 Aggregator의 자료구조를 노출하지 않아도(혹은 몰라도) 내부 데이터에 접근할 수 있는 방법.

 

Strategy

기능의 특정 부분을 실행중에 다른것으로 효과적으로 변경하는 기능 제공

필요할 경우 전략을 바꿀 수 있는 패턴

단계 1, 2, 3, ..., N 진행하다가 단계3을 변경하는 등

 

Template

어떤 기능에 대해실행 되어야 할 각 단계에 대한 순서만 정의

세부 구현(코드)은 상황에 맞게 작성하도록 하는 패턴

 

어떤 기능에서, 단계 1-2-3으로 실행 한다는 템플릿이 있다고 하자.

각 단계에 대한 구체적인 코드는 없고 상황에 맞게 구현하는 것이다.

즉, 템플릿이 선언만 되어있기에 추상클래스 형식으로 작성할 수 있다. 

 

Adapter

이름처럼 어댑터를 통해 원하는 형태로 변환해주는 기능을 함.

어떤 클래스를 사용하고자 하는데, 특정 이유 때문에 그대로 사용해야 할 때(그 클래스의 코드를 변경할 수 없을 때) 어댑터로 변경해서 사용할 수 있다. (그 클래스의 어댑터를 이용해서)

 

Bridge

기능 계층, 구현 계층의 분리를 통해 시스템의 확장성&유지보수성을 높이는 패턴.

 

기존 기능에 대해서 구현 계층을 통해 확장이 용이.

또한, 기존 시스템에 새로운 기능을 추가하더라도 기능 계층을 통해 코드 변경을 최소화 가능.

 

기능 계층 - 새로운 기능을 위한 메서드 추가 클래스를 포함

구현 계층 - 이미 정해진 인터페이스에 대한 구현 클래스를 포함

기능 - 구현 계층을 연결한다는 의미에서 Bridge패턴.

 

Singleton

어떤 클래스에 대해 하나의 객체만 생성될 수 있게 보장하는 패턴.

다른 클래스에서 접근은 가능하지만, 생성은 불가.

 

Flyweight

어떤 객체를 사용하고자 할 때 매번 생성하지 않고, 한 번만 생성해서 재사용하는 패턴

객체 생성을 위해 많은 자원을 소모하게 되는 경우 이 패턴을 적용해서 자원을 훨씬 아낄 수 있다.

 

Composite

단일체와 집합체를 하나의 동일한 개념으로 처리하기 위한 패턴

단일체는 구슬과 같고 집합체는 상자와 같음. 상자에 구슬을 담는.

 

단일체와 집합체로 여러가지 상황을 만들 수 있는데

예) 구슬, 상자, 상자&상자에 담긴구슬, 상자와 구슬을 담은 상자 등

 이 상황들을 단 하나의 개념으로 처리해서 단순하게 만드는 패턴.

 

Factory method

객체 생성을 위한 패턴.

객체 생성에 필요한 과정을 미리 정해놓고, 각 과정을 다양하게 구현 가능

이 점을 통해 객체 생성에 필요한 전처리/후처리가 유연함.

원하는 시점에서 생성하려는 클래스를 구체적으로 정해 생성할 수 있는 유연성 제공.

객체 생성에 대한 인터페이스, 구현을 분리 => 시스템 확장성&유지보수성 상승

 

Observer

어떤 대상의 상태가 변경되었을때, 그 상태 변화에 관심이 있는 관찰자들에게 알려주는 패턴

예) 주사위 게임을 할 때, 주사위를 던지면 게임에 참가한 모든 플레이어에게(관찰자) 바뀐 주사위의 값(상태 변화)을 보여주는 등

 

Mediator

각 객체들이 서로 관계를 맺음으로써 다른 객체를 서로 조작 할 때, 그 관계에 참여하는 객체 수가 많아지면 복잡도가 매우 증가한다. 

이 복잡한 관계를 단순화 시키기 위해 중재자(Mediator)를 두어, 각 객체들이 다른 객체와 관계를 맺는 것이 아니라 오직 중재자와 맺도록 한다. 

이처럼 중재자가 변경 사항을 각 객체들에 통지해 줌으로써 객체들을 조작하여 복잡한 관계를 단순화시킨 패턴.

 

Memento

추억, 기억이란 뜻에 걸맞게

객체의 상태를 기억해 두었다가 필요할 때 그때의 상태로 객체를 되돌린다.

객체의 상태에 대한 기억은 다른 객체에서도 접근할 수 있어야 하지만, 읽기 전용이도록 해야 한다.(기억을 조작하면 안 되니)

또한, 기억은 오직 해당 객체만 생성할 수 있어야 한다. (다른 곳에서 엉뚱한 기억을 생성할 수 없도록)

 

Proxy

대리인 이란 뜻처럼, 어떤 작업의 실행을 대리인을 통해 실행하도록 하는 패턴

예) 어떤 문자열을 출력할 때 ScreenDisplay를 사용하지 않고 BufferDisplay의 객체를 대신 사용.

예시의 사례에서 ScreenDisplay로 문자열을 바로 출력하면 ScreenDisplay의 print 메서드가 출력을 위한 준비작업에 많은 시간을 소요한다. (매번 호출되니)

이를 더 빠르게 하려면, 출력할 문자열을 최대한 모아서, print메서드는 최소한으로 호출하면 된다.

이를 위해서 BufferDisplay에 문자열을 모아뒀다가 특정 개수가 모였을 때 한꺼번에 출력.

그 외의 다른 Proxy대표적 예시로, 어떤 요청에 대해 결과를 캐시처럼 저장 한 후 새로운 요청이 이전 요청과 동일하다면 일하는 객체가 또 일하게 하지 않고 캐시에 저장했던 정보만 바로 전달해 주면 됨. 속도향상&CPU자원 절약 효과

 

Decorator

객체의 기능을 마치 장식하듯 계속 추가하는 패턴

실행 중에도 동적으로 기능을 붙일 수 있으므로 SW확장성이 매우 높아짐

 

Chain of responsibility

여러개의 "뭔가를 처리하는 기능(클래스 단위)" 들을 동적으로 연결해 순차적으로 실행하는 패턴

각 기능을 클래스 별로 분리해서 구현함으로써 기능에 대한 클래스의 독립성이 보장됨 => 최적화된 코드 작성 가능

예) URL에서는 프로토콜-도메인-포트 각각 역할들이 클래스별로 구분되어있지만 chain처럼 연결되어 순서대로 수행된다.

 

Prototype

객체를 생성하는 패턴

보통 객체의 생성은 클래스를 통해 이루어지며, 클래스 이름 앞에 new 키워드를 씀으로써 가능한데

Prototype패턴의 경우 "new 클래스이름" 이 아니라 이미 생성된 객체를 통해 독립된 또 다른 객체 생성

이 방법을 통해 생성된 객체는 그 상태를 변경해도 원본객체의 상태가 변경되지 않는다.(깊은 복사를 마련해주므로)

새로운 클래스를 추가하지 않고도 새로운 개념의 객체를 생성할 수 있는 상황이라면, Prototype패턴을 사용해 유연성을 발휘할 수 있다.

 

Facade

어떤 기능을 실행하기 위해서는 여러 클래스들의 객체를 사용해야 함.

이 때 여러 그 객체들 사이에 복잡한 관계와 사용을 감춰서 단순하게 만들어 주는 패턴.

예1 ) 어떤 데이터를 조회해서 출력하고싶을 때 원래라면 Cache 조회, DBMS조회, Cache에 입력, 조회 결과 가공, 가공 결과 출력 등 수많은 클래스의 객체를 사용해야 한다.

여기에서 Facade를 적용하면 객체들의 메서드를 파악하지 않고도 Facade에 해당하는 클래스 하나만 사용하도록 단순화 할 수 있다.

예2) 다른 개발자에게 라이브러리나 패키지를 제공할 때 Facade를 적용한다면 유용하다. Facade에 해당하는 클래스만 공개하고 그 외 나머지 클래스는 비공개 처리해도 된다는 장점도 있기 때문이다.

 

Builder

복잡하게 구성된 객체를 효과적으로 생성하는 패턴

다른 패턴과 달리 2가지 내용이 있다.

1. 객체를 생성 할 때 생성자의 인자 개수가 많으면, 각 인자를 독립적으로 명확하게 지정하는 패턴

2. 객체를 생성 할 때 여러 단계를 순차적으로 거친다면, 이 단계에 대한 순서는 결정해두고 각 단계를 다양하게 구현하도록 하는 패턴

 

Command

명령을 객체화 한 패턴

명령(기능)을 객체화 하면 메서드의 인자를 통해 전달도 가능하고 메모리에 보관도 가능해짐.

메모리 뿐 아니라 DBMS같은 저장소에도 저장 가능하니, 데이터가 아닌 행위를 저장이 가능해짐.

또 네트워크를 통해 다른 컴퓨터에 전달 해 기능을 수행할 수도 있다.

이처럼 기능을 자유롭게 보관/전달 가능해지면 배치 실행(기능을 모아 한번에 실행), Undo/Redo, 우선순위순 기능 수행 등 유연성 발휘가 가능해짐.

 

Abstract Factory

만들어야 할 컴포넌트를 추상적으로 정해놓고, 추후 구체적인 상황이 주어지면  앞선 추상 컴포넌트들을 해당 상황에 맞게 구체화 하는 패턴

예) Button, CheckBox, TextEdit 컴포넌트들을 만들어야 한다고 하자.(추상적 정의)

이들은 OS에 따라 만드는 방법이 달라지므로 당장 구체적으로 만들 수 없다.

그러나 Windows라고 정해지는 순산이 오면 그 때 구체적으로 생성하는 것.

 

State

어떤 상태를 클래스로 표현해서 객체로 다룰 수 있도록 하는 패턴

보통 어떤 상태의 조건을 따질 때 if조건문을 사용하곤 하는데, 많은 if 조건문은 서로 다른 조건문에 영향을 주게 되어 복잡해져버린다. 

이 때 State를 사용하면 if 조건문을 줄여주어 효과적으로 코드 작성이 가능하다.

 

Interpreter

문법에 맞춰 작성된 스크립트를 해석, 해석된 구문을 규칙대로 실행하는 패턴

예)