DesignPattern

## Intro

Algorithm과 object 간의 책임 분배에 관한 pattern입니다.

즉, object의 사용 목적에 따라서 method를 정의할 때, 많이 사용되는 구현 pattern을 의미합니다.

## Behavioral Pattern

### 1. Chain of Responsibility(CoR)

![cor](/images/cor.jpeg)

**request를 여러 handler들을 하나의 chain으로 연결한 object에 전달하여 request를 처리하는 방식입니다.** 여기서 각 각의 handler는 스스로 작업을 끝내고 response를 보낼 수도 있고, 이를 다음 handler로 전달할 수도 있으며, 해당 request를 이용해서 side effect를 만들 수도 있다.

이는 대게 request를 처리하는 module을 설계하는 과정에서 많이 사용됩니다. 예를 들어, REST API 를 구현하고자 할 때, 여러 request에서 공통적으로 사용되는 logic을 별도의 middleware라는 것으로 분리하여 구현하고 재활용하는 것을 많이 볼 수 있습니다. (ex. nodeJS express, Go http.Handler, etc...)

---

여기서 CoR의 특징을 살펴보고 갑시다.

- Request의 처리 순서도 제어할 수 있습니다.
- 각 handler가 하나의 역할만 하도록 하여, 유연성과 가독성을 높일 수 있습니다.(Single Responsibility)
- 새로운 handler의 추가가 기존 code의 영향을 주지 않습니다. (Open/Close)

### 2. Command

![command](/images/command.jpeg)

**모든 request를 하나의 queue에 저장하고, 처리자는 queue의 순서에 따라서, request를 처리하는 pattern입니다.** 이러한 방식은 request를 마치 하나의 method paratemer로 받아들이도록 하고, request의 실행을 queue로 관리함으로써, 쉽게 되돌리기 기능도 지원하도록 할 수 있습니다.

쉽게 예를 들면, 식당에서 웨이터는 주문을 받아서, 영수증을 순서에 따라서 order board에 붙이면, 주방장은 이를 보고, 순서에 따라서 요리를 내보내는 형식이라고 보면 되겠습니다.

구현 시에는 Command라는 Interface를 구현하는 각각의 Command class를 작성합니다. 여기서 각 Command는 생성 시에 receiver를 전달받아서, 호출 시에 이를 Receiver에게 전달할 수 있도록 합니다. 그리고, Command Interface를 호출하는 Invoker를 선언해줍니다.

---

Command의 특징은 다음과 같습니다.

- Command 단위로 class를 구분할 수 있기 때문에 유연성이 높아집니다. (Single Responsibility)
- 새로운 Command의 추가가 기존 code에 영향을 주지 않습니다. (Open/Close)
- 되돌리기와 다시 재생 등의 동작의 구현이 쉽습니다.

### 3. Iterator

![iterator](/images/iterator.jpeg)
**내부의 구현물을 들어내지 않은 상태에서 구성요소를 순환하기 위해 고안된 pattern입니다.**

기본적으로는 iterator는 다음과 같은 요소로 이루어집니다.

1. 현재 자신의 구성요소를 retuern하는 method
2. 다음 iterator를 반환하는 method
3. 다음 iterator가 존재하는지를 체크하는 method

해당 object를 통해서 전체 구조를 순환할 수 있도록 하는 방식입니다. 주요 예시는 file 입출력을 예를 들 수 있습니다. 대게 while 문을 통해서 더 이상 읽을 문자가 없을 때까지 line 단위로 받아오며, next를 호출하는 식의 구현을 많이 보았을 것입니다. 이를 사용하는 이유는 두 가지로 들 수 있습니다.

1. object 내의 자세한 구현을 감추기 위해서
2. 필요에 따라 여러 iterator를 생성하기 위해서

대게 object가 하나 이상의 동일 object를 포함하게 된다면, 이 object를 순환할 수 있는 방법은 여러 가지가 존재하게 됩니다. 예를 들어 tree를 구현했다고 했을 때, 기본적으로 depth first search, breadth first search을 생각할 수 있습니다. 하지만, 상황에 따라서 효율적인 방식이 다르기 때문에, 각기 다른 순환 방식을 지원하는 것이 좋습니다.

---

iterator의 특징을 살펴보고 갑시다.

- Iterator 각 각에 필요로 하는 algorithm을 구현할 수 있기 때문에 유연한 구조를 가질 수 있습니다. (Single Responsibility)
- 새로운 iterator의 추가가 기존 code에 영향을 미치지 않습니다. (Open/Close)
- object로부터 생성된 각 iterator는 서로 독립적으로 동작할 수 있습니다.
- 하지만, 해당 구현은 다루고자 하는 데이터의 양이 적은 경우 지나칠 수도 있고, 직접 접근하는 것보다 속도가 느릴 수 밖에 없습니다.

### 4. Mediator

![mediator](/images/mediator.jpeg)

object 간의 혼란스러운 의존성을 줄이기 위해서 고안된 pattern으로, **object 간의 직접적인 사용을 제한하고, mediator라는 중계자를 통해서만 동작할 수 있도록 하는 pattern**입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 디양한 object 간의 communication을 추출할 수 있기 때문에, object 본연의 작업에 집중하여 편리하고 유지하기 쉽게 만듭니다. (Single Responsibility)
- 새로운 mediator를 추가할 때, 기존 code의 변경이 필요 없습니다. (Open/Close)
- 각 Object 간의 의존성을 제거할 수 있습니다.
- 개발이 진행될수록 mediator가 전체 시스템을 관리하는 a God Object가 되고, mediator를 사용하는 모든 object가 이에 의존성이 생기게 됩니다.

### 5. Memento

![memento](/images/memento.jpeg)

object의 상태 변경에 이전 상태가 큰 영향을 미치거나 history에 대한 구현이 필요한 경우 구현할 수 있습니다. **object의 구체적인 구현에 대한 내용을 제외하고, 이전 상태를 저장하고, 필요에 따라 이를 다시 불러와서 사용하는 pattern**입니다.

구현을 하기 위해서는, 본래의 object를 그대로 두고, 필요로 하는 private variables를 포함하는 memento를 구현하여 state를 받을 수 있는 method를 포함하게 해서, 이 memento들만 caretaker라는 object에서 list형태의 history로 저장할 수 있도록 합니다.

---

memento의 특징은 다음과 같습니다.

- 기존 object의 encapsulation을 유지하면서, 기능을 구현할 수 있습니다.
- 기존 code를 그대로 유지한 채로 caretaker를 통해서, history logic을 작성할 수 있습니다.
- 그러나, memento를 유지하기 위한 추가적인 공간이 필요하며, 오래된 데이터 삭제를 위한 원본을 향한 추적이 필요로 됩니다.

### 6. Observer

![observer](/images/observer.jpeg)

가장 많이 쓰이면서, 중요한 pattern 중에 하나라고 생각합니다. **subscription 로직을 정의하고, subscription을 수행한 모든 object에게 특정 event의 발생을 전달하는 방식입니다.**

즉, object에서 특정 event가 발생하면, 이를 계속해서 broadcasting 하는 방식입니다. 따라서, 이를 구독하고 있는 각 object가 이에 따른 처리를 수행하는 방식입니다.

구현을 하기 위해서는,

Command Pattern과 굉장히 유사하다고할 수 있습니다. Command Pattern은 Queue에 Command를 차곡차곡 쌓아두고, 이를 사용하기를 원하는 Object가 이를 찾아가는 방식이라면, Observer Pattern은 저장하기보다는 이를 필요로 하는 Object에게 전달하는 방식입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 새로운 Subscriber, Publisher가 기존 code에 영향을 미치지 않습니다. (Open/Close)
- 실행 중에 object간의 관계를 생성하는 것이 가능합니다.
- 그러나, Subscriber 간의 순서를 정의하거나 각 event의 순서를 엄밀히 구현하는 것은 별도의 구현체를 필요로 합니다.

### 7. State

![state](/images/state.jpeg)

**object의 내부 상태가 변화할 때마다 동작을 바꾸도록 하는 pattern입니다.** 마치 object가 이것의 class를 바꾸는 것과 같은 효과를 볼 수 있습니다.

가장 일반적으로 볼 수 있는 예시가 게시글 작성이다. 엄격한 절차를 따르는 글 작성에는 다음 세 가지의 과정을 거치게 됩니다.

1. 제출 전
2. 제출 완료 (검토 중)
3. 배포 (업로드 완료)

각 단계마다 사용할 수 있는 method와 각 method의 동작이 달라질 수 있습니다. 이를 별도의 class로 나누지 않고, 하나의 class로 만들면서 state를 포함하도록 함으로써, 이를 내부에서 control 할 수 있도록 하는 pattern입니다.

구현 시에는 각 State를 별도의 Class로 분리하고, 그 내부에서 변경되는 method를 직접 구현하도록 합니다. 따라서, 실제 state를 포함한 원본 class는 이 state에 정의된 method를 호출하도록 할 수 있습니다.

---

state의 특징을 살펴보고 갑시다.

- 별도의 state를 class로 분리하기 때문에, 유연한 구조를 만들 수 있습니다. (Single Responsibility)
- 새로운 state의 추가가 기존 code에 영향을 주지 않습니다. (Open/Close)

### 8. Strategy

![strategy](/images/strategy.jpeg)

동일한 method에 대해서 여러 algorithm을 정의하고, 각각을 별도의 class로 나누어 상호 호환이 가능하도록 하는 pattern입니다.

**즉, object의 method 자체를 별도의 interface로 분리하는 방식이라고 이해할 수 있습니다.** 앞서 보았던 state는 context(문맥)에 따라서, 상태가 바뀌지만 Strategy Pattern에서는 행위 자체가 바뀐다고 생각하면 됩니다.

대게 게임에서 쉽게 예시를 생각할 수 있습니다. player의 skill을 interface화 시키고, 해당 동작에 따른 damage와 mp 변화 등을 각 skill마다 직접 계산하여 player object로 전달할 수 있다고 생각하면 쉽습니다.

---

strategy의 특징을 살펴보고 갑시다.

- 실행 중의 특정 strategy를 선택하여 실행시키는 것이 가능합니다.
- 각 strategy에 대한 자세한 구현을 감출 수 있습니다.
- 대게 상속 형태를 대체하여 사용하는 것이 가능합니다.
- 새로운 strategy의 추가가 기존 code에 영향을 미치지 않습니다. (Open/Close)

### 9. Template Method

![templateMethod](/images/templateMethod.jpeg)

**algorithm의 skeleton을 상위 class에 정의하고, 전체적인 구조는 바꾸지 않으면서 각 단계에 대한 구현을 override 하는 pattern입니다.**

따라서, 전공과목 과제를 하다 보면 교수님들이 skeleton 코드를 준다고 했을 때, 대게 구조만 있고, 각 함수의 내부가 비어 있는 것을 볼 수 있었던 거 같습니다. 따라서, 해당 class를 inherit 하여 구체적인 구현을 하는 식으로 class를 만들면 됩니다.

---

template method의 특징은 다음과 같습니다.

- 구현의 내용을 줄이고, 중복되는 코드의 사용을 줄일 수 있습니다.
- 그러나, skeleton에 의한 제한으로 불가피하게 code의 변경이 발생할 수 있습니다.

### 10. Visitor

![visitor](/images/visitor.jpeg)

**특정 object에 접근하려는 object에 따라 별도의 algorithm을 적용하는 pattern입니다.**

즉, 사용하고자 하는 object를 하나의 interface로 추상화하고, 각 object는 이를 사용할 client(visitor)를 허용할 것인지 그리고 어떤 algorithm을 수행할 것인지를 정의해둡니다. 사용할 수 있는 예시는 사용할 수 있는 Element의 종류가 매우 다양하며 계속해서 추가될 가능성이 높을 때 사용할 수 있습니다. 그렇지만, Visitor의 추가는 매우 어렵기 때문에 이에 유의해야 합니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 새로운 algorithm의 추가가 기존 code의 변경없이 가능합니다. (Open/Close)
- 동일한 class 내부에서 동일한 동작을 여러 version으로 정의할 수 있어 유연합니다. (Single Responsibility)
- 그러나, visitor의 추가는 기존 algorithm의 수정을 불러올 수 있습니다.

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Refactoring GURU : [https://refactoring.guru/design-patterns/structural-patterns](https://refactoring.guru/design-patterns/structural-patterns)
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 4. Behavioral Pattern

## Intro

앞 서 살펴본 creational pattern이 object의 생성에 대한 방법들을 제공하였다면, 해당 object들의 관계를 어떻게 연결할 것인가에 대한 고민에서 만들어진 pattern이라고 생각하시면 됩니다.

예를 들어서, 외부 라이브러리와 내부 모듈 간의 상호작용이나 이들을 연결하는 방식을 정의하는 것이 일반적으로 가장 많이 사용되는 경우라고 볼 수 있습니다.

## Structural Pattern

### 1. Adapter

![adapter](/images/adapter.jpeg)

object와 object간의 상호작용을 돕는 가장 기본적인 방법입니다. 제 생각에는 **Converter로** 표현할 수 있을 거 같습니다. 예를 들어, pdf를 필요로 하는 module이 있다고 했을 때, 우리가 가진 것이 이미지밖에 없다면, 우리는 이를 변환해줄 수 있는 converter를 중간에 설치함으로써 이들을 수정해주지 않고, 합칠 수 있을 것입니다. 이러한 방식이 바로 Adapter pattern의 핵심이라고 할 수 있습니다.

일반적인 구현은 adapter라는 class를 변환 결과물의 class의 확장(상속)으로 둡니다. 이렇게 하면, 해당 class의 속성을 모두 가집니다. 여기서 adapter의 생성 시에 변환 전의 class를 전달하여, 내부 구현을 overriding 하는 방식을 취하도록 하는 방법입니다. **즉, adapter 자체가 원하는 제품의 변환 완료 상태라고 보시면 됩니다.**

refactoring.guru 사이트에서 예시를 든 상황을 봅시다.

원형 구멍에 원기둥을 넣으면서, 원형 구멍보다 반지름이 큰 원기둥은 filtering하는 코드가 있었다고 합시다. 이때, 원기둥이 아닌 직육면체를 넣고 싶다면, 어떻게 해야 할까요? 직육면체를 마치 원기둥처럼 받아들일 수 있도록 직육면체의 밑변의 변의 길이를 통해서 반지름을 생성해내는 로직을 가진 adapter를 만들어내면 될 것입니다.

---

여기서 adapter의 특징을 살펴보고 갑시다.

- 기존의 변환 결과물로 돌아가는 코드를 그대로 사용하는 것이 가능합니다.
- 대게 data의 변환 시에 많이 사용됩니다. (ex. XML -> JSON)
- 사실 임시 방편이라고 볼 수도 있습니다. 위에 원형 구멍에 넣을 수 있는 것을 원형기둥으로 제한한 상황에서 직육면체를 넣었다는 것에서부터 가독성이 떨어지고, 복잡도가 높아질 수 있는 것입니다.

### 2. Bridge

> before

![bridge-1](/images/bridge-1.jpeg)

> after

![bridge-2](/images/bridge-1.jpeg)

하나의 class의 크기가 너무 비대해지거나 각 class들 간의 의존성이 높아지는 경우에 이를 두 개의 계층 구조로 나누어 의존성을 제거하면서 개별적으로 개발하는 환경을 만드는 방식입니다.

개발을 진행하다 보면, 하나의 class의 크기가 굉장히 비대해지는  경험을 할 수 밖에 없습니다. 예를 들어서 처음에는 단순히 버튼이라는 class를 만들었었는데, 디자인의 detail을 위한 내용에 의해서 코드가 굉장히 비대해지고, 이를 click 했을 때, hover 했을 때와 같은 로직도 계속해서 추가되면서 class가 비대해지는 것을 볼 수 있습니다. 따라서, 여기서 design 부분을 별도의 class로 분리시키고 이를 기존 button class가 변수로 포함하는 방식이라고 생각할 수 있습니다.

**즉, 여러 구현 method, attribute를 하나의 attribute type으로 통합하고, 이를 interface로 만들어 사용하는 것입니다.** 이렇게 함으로써 좀 더 유연한 구조를 가질 수 있습니다. 사실 우리의 main application이 module을 직접 구현하지 않고, 여타 module을 install하여 사용하는 것도 이와 유사하다고 할 수 있겠습니다.

---

여기서 bridge의 특징을 살펴보고 갑시다.

- 대게 design(css style)/platform(ios, android, web)과 logic을 분리하여 서로간 의존성을 분리할 때, 유용합니다.

### 3. Composite

![composite](/images/composite.jpeg)

**object들을 tree 구조로 만들어**서 마치 하나의 object 인 것처럼 동작시키는 방법입니다. 그렇기에 만들고자 하는 구현 목표 자체가 tree 구조로 표현 가능할 때에만 사용 가능합니다. tree는 자신의 기능을 담는 root와 다른 subtree들로 이루어지며, 이들을 가리키는 pointer를 가진다.(subtree는 없을 수도 있다.)

대게 구현을 위해서, 가장 기반이 되는 기능을 interface type으로 생성하면, leaf처럼 사용될 class와 이를 담을 수 있는 형태의 class로 나누어 구현합니다.

예를 들면, file system을 예로 들 수 있습니다. file system은 크게 file과 folder로 나뉘어집니다. folder는 마치 하나의 subtree가 되는 것이고, file은 하나의 leaf가 되는 것이라고 생각할 수 있습니다. 각 leaf마다 알맞은 구현을 할 수 있고, folder에도 알맞은 구현을 쉽게 구현하는 것이 가능합니다.

---

여기서 composite의 특징을 살펴보고 갑시다.

- 계층으로 이루어지는 복잡한 구조를 쉽게 구조화할 수 있습니다.
- 새로운 요소를 추가할 때에도, 기존 코드에 영향을 주지 않습니다.
- 그러나, 억지로 도입하기 위해서, 과도하게 일반화한 구조를 가지게 되면, 이해하기 어려운 구조가 될 수 있습니다. 즉, tree를 구조를 가진다는 것이 명확할 때에만 사용하는 것이 좋습니다.

### 4. Decorator

![decorator](/images/decorator.jpeg)

**새로운 기능들을 object에 추가하기 위해서 기존 object는 그대로 두고, 새로운 기능을 포함하는 wrapper로 감싸주는 방식입니다.**

만약, 핸드폰 push 알림 기능을 구현해놓았고, 이를 여러 업체에게 배포하였다고 가정합시다. 그런데, 어떤 업체에서는 Facebook 알림, 또 다른 업체에서는 Slack 알림을 추가로 전송하기를 원한다면, 어떻게 해야 할까요? 가장 쉽게 생각 나는 방법은 각 notification 기능을 수행할 수 있는 class를 생성하고, app에서 여러 개를 생성해서 보내는 방법일 것입니다. 하지만, 단 하나의 object만 받을 수 있도록 구현이 되어 있고, 이를 실행시키는 app code를 변경할 수 없다면, 우리는 결국 3 가지의 알림을 하나의 class로 구현하기 위해서, 7개의 class가 필요합니다.

1. push 알림만 있는 class
2. facebook 알림만 있는 class
3. slack 알림만 있는 class
4. push + facebook 알림 class
5. push + slack 알림 class
6. slack + facebook 알림 class
7. push + slack + facebook 알림 class

이러한 구조를 가지는 거는 굉장한 중복 코드를 만들어낼 가능성이 있습니다. 그래서 나온 pattern이 decorator입니다. 기존 object에 새로운 기능을 하는 object를 감싸는 방법입니다. 실행 시에는 밖 or 안부터 실행을 시키면서 진행합니다.

---

여기서는 decorator의 특징을 살펴봅시다.

- 이 역시 기존 코드의 수정이 필요 없습니다.
- runtime에 쉽게 새로운 구현을 추가하거나 삭제할 수 있습니다.
- 각 wrapper가 하나의 기능만 하도록 구현하여, responsibility를 하나만 갖도록 할 수 있습니다.
- 그러나, 때로는 wrapper간 의존성으로 인해 특정 wrapper를 제거할 수 없는 경우가 생길 수도 있습니다.

### 5. Facade

![facade](/images/facade.jpeg)

**간소화된 interface를 복잡한 class 구조(library, framework)에 간단한 interface를 제공하는 pattern입니다.** 즉, third party를 사용할 때, 직접적으로 호출하는 것이 아닌 facade라는 object를 통해서 추상화한 method를 사용하도록 함으로써 실제 시스템과 third party와의 의존성을 줄이는 방식입니다.

---

facade의 특징은 위에서 말한 바와 같고, 주의사항이 하나 존재합니다.

- facade가 모든 object들의 구현을 아는 a god object가 될 수도 있습니다. 이렇게 되면, 사실상 이를 이용하는 application도 결코 system에 독립적일 수 없습니다.

### 6. Flyweight

> before

![flyweight-before](/images/flyweight-before.jpeg)

> after

![flyweight-after](/images/flyweight-after.jpeg)

object를 유지하는데 비용을 너무 많이 사용하기 때문에, **일반적으로 사용되는 동일한 부분을 별도로 object에 포함시키지 않고 공유하도록 함으로써 object를 경량화하기 위해서 나온 pattern입니다.**

---

Flyweight의 특징은 다음과 같습니다.

- RAM의 사용량을 줄인다는 것은 그만큼 CPU 사용량이 늘어난다는 것을 의미합니다.
- 또한, Computer를 위한 설계이니 만큼 사람이 이해하기에 가독성이 떨어질 수 있습니다.

### 7. Proxy

![proxy](/images/proxy.jpeg)

대체 object를 제공하거나 또 다른 object를 위한 placeholder를 제공하는 pattern이다. original object에 접근을 제어하면서, 요청의 처리 전 후로, 특정 동작을 수행하도록 할 수 있습니다.

가장 많이 사용되는 사례는 당연하게도 Database에 접근하는 로직을 정의하는 API를 만드는 경우를 예로 들 수 있습니다. API server는 사실상 database에 접근하기 이전에 수행해야 할 동작들을 미리 정의하고, 요청이 들어오면 이를 처리하여 client에게 전송하는 방식으로 구현되어 있습니다. 이것이 필요한 이유는 민감정보의 보호와 서비스 데이터를 안전하게 보장하기 위함이라고 할 수 있습니다.

따라서, 해당 object만으로도 사용이 가능하지만, 요구에 따라서, object 접근 전후로 처리가 필요한 경우 proxy pattern을 통해서 구현하는 경우가 많습니다.

---

Proxy의 특징은 다음과 같습니다.

- service와 이를 이용하는 client와 독립적으로 구현이 가능합니다.
- 일반적으로 service에 직접 접근하는 것보다 delay가 발생할 수 밖에 없습니다.

## Reference

중간에 좋은 reference를 찾았기 때문에 여기서부터는 출처가 바뀝니다. 저도 해당 사이트의 도움을 많이 받았기 때문에 해당 사이트 한 번 직접 가보는 것을 추천드립니다.

- Design Patterns: Elements of reusable object oriented software.
- Refactoring GURU : [https://refactoring.guru/design-patterns/structural-patterns](https://refactoring.guru/design-patterns/structural-patterns)
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 3. Structural Pattern

## Intro

object의 instantiation을 추상화하는 방법입니다.

즉, instance를 만들 때, 어떻게 하면 재사용과 변경에 유용한 구조로 만들 수 있을까에 대한 고민의 결과로 나온 pattern이라고 볼 수 있습니다.

일반적인 순서로는 Abstract Factory, Builder, Factory Method, Prototype, Singleton이지만, 제가 이해하기 쉬운 순서대로 정리하겠습니다.

모든 가정은 App이라는 main class에서 product1과 product2라는 object가 필요하다는 가정하에서 이를 어떻게 얻어오는지에 대해서 살펴보겠습니다.

## Creational Pattern

### 1. Singleton

![singleton](/images/singleton.jpeg)

가장 먼저 알아볼 것은 Singleton 입니다. 가장 기본이기에 가장 중요한 design pattern 중에 하나라고 생각합니다.

우리가 특정 object가 필요할 때, 해당 대상을 단 하나만 만들어서 이를 전역에서 접근하도록 하여 구현하는 방식을 의미합니다.

당연히 이 방식을 이용하게 되면, zero copy라는 측면에서 효율이 굉장히 좋을 것입니다. 하지만, 이러한 pattern을 남용하게 된다면, 누가 이 product에 접근하고 있는지 그리고 누가 변경했는지 알기 어려워집니다. 따라서, **해당 Singleton에서 중요한 점이라면, 변하지 않는 값만 가지도록 하는 것입니다.**

이를 통해서, 누가 이를 사용하더라도 시스템에는 영향을 안 주면, zero copy로 사용하기 때문에 굉장히 효율상으로도 훌륭하게 사용할 수 있습니다.

하지만, maintainable의 입장에서는 큰 약점이 될 수 있습니다. 하나의 구현을 바꾸게 된다면, 전체 시스템이 어디서 어떻게 영향을 받는지 알 수 없기 때문에 이 점에서는 약점을 가지고 있습니다.

하지만, 우리가 다루는 object에 변화가 필요하고, 능동적인 조작이 필요한 경우에 object 자체로 singleton으로 만드는 것에는 제한이 생깁니다. 따라서, 우리는 object의 instance를 대신해서 생성해주는 factory라는 개념을 사용하게 됩니다. (이들을 singleton으로 만드는 것이 좋습니다.)

이는 저번 챕터 1에서 보았던 delegation을 활용한 것입니다. 자신이 사용하고자 하는 object의 instantiation을 다른 object에게 맡기는 형식입니다. 이를 통해서, 본연에 하고자 하던 행동에 좀 더 집중할 수 있습니다.

---

다음으로 넘어가기 전에, 한 번 더 머릿속에 정리합시다. 지금의 App이 알고 있는 사항은 무엇일까요?

어떤 내용도 추상화를 통해서 감추지 않았기 때문에, 우리는 productA, productB라는 object가 정확하게 무엇인지 알고 있고, 이를 만드는 방법까지도 완벽하게 알고 있는 상태입니다.

### 2. Builder

![builder](/images/builder.jpeg)

가장 쉽게 object의 생성을 맡긴다고 했을 때, 상상할 수 있는 구조입니다. IBuilder라는 interface를 통해서 builder를 묶어줄 수도 있지만, 단순히 각 object(product)에 대한 builder를 생성해줄 수도 있습니다.

**여기서 중요한 개념은 각 product에 대한 전문 생성자를 구축한다는 점입니다.** 내가 만들고자 하는 object에 대해서 이것만을 전문적으로 만들 수 있는 class를 singleton으로 생성함으로써, 쉽게 무언가의 제품을 만들고 싶다면, 이 builder에게 맡기면 되겠다는 식의 발상으로 이어질 수 있습니다.

builder는 얻고자 하는 product에 대한 모든 내용을 추상화해버리기 때문에, 내부의 코드가 정교하게 만들어지고 변화가 없다면, 매우 좋게 작동할 수 있습니다. 하지만, product 하나를 여러 object들이 사용한다면, 후에 변경이 매우 어려워질 수 있습니다.

---

자 이번에도 넘어가기 전에, 한 번 더 머릿속에 정리합시다. 지금의 App이 알고 있는 사항은 무엇일까요?

우리는 현재 builder라는 대상에게 object의 생성을 넘겼습니다. 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지 알고 있지만, 이를 만드는 방법은 모르는 상태입니다.

### 3. Abstract Factory

![abstractFactory](/images/abstractFactory.jpeg)

이제 그림이 조금 복잡해집니다. 여기서는 좀 더 복잡한 상황을 고려한다는 것을 직감적으로 받아들이시면 됩니다.

이제 우리는 만들고자 하는 object도 어떤 부류 중에 하나다 정도로만 알 수 있습니다. 이 상황에서 우리는 이를 만들고자 하는 object 마저 추상화를 한 것을 볼 수 있습니다.

또한, 우리는 Factory를 Singleton으로 만들어야 한다는 점에도 주목해야 합니다.

결국 모든 생성의 대한 권한은 factory에게 넘어갔고, 필요에 따라서 우리는 특정한 factory를 골라서 사용하면 됩니다. 마찬가지로 product 역시 필요에 따라 골라서 사용하면 됩니다.

하지만, 이 pattern은 굉장히 비싼 pattern이라고 볼 수 있습니다. 후에 지원하고자 하는 product 자체를 하나 더 만든다면, (ProductC) 이를 추가하기 위해서 모든 Factory는 이를 생성할 수 있도록 변경이 되어야 할 것입니다.

---

그럼 이번에는 어떨까요?

우리는 현재 factory라는 대상에게 object의 생성을 넘겼습니다. 또한, product 또한 추상화를 통해서 이것이 무슨 기능을 하는지는 어렴풋하게 알고 있지만, 이것이 정확하게 무엇인지는 모릅니다.(예전에는 정확하게 구두라고 지정했다면, 이번에는 두루 뭉술하게 신발이라고 쓰고 이를 사용하고 있다고 생각하시면 됩니다.) 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지도 모르고, 이를 만드는 방법 또한 모르는 상태입니다.

### 4. Prototype

![prototype](/images/prototype.jpeg)

Prototype의 뜻부터 알고 가면 좋습니다. 이는 하나의 type을 대표할 수 있는 전형적인 예, 원래의 형태 정도로 해석할 수 있습니다. 즉, 특정 부류를 설명할 수 있는 전형적인 예에서 부터 확장을 시작한다는 개념으로 받아들이는 것이 좋습니다.

기존의 Interface를 이용하는 방식은 대상이 정확하게 무슨 기능을 할 수 있는지에 대한 엄격한 선언이 있었다면, 해당 방식에서는 다소 느슨하다고 할 수 있습니다. 전형적인 예인 prototype에서부터 시작하여 이를 확장하여 표현한다는 것이 일반적인 견해라고 할 수 있습니다. 따라서, 구현도 Factory에서 Prototype을 가지고 이를 Clone 하여서 instantiating을 수행하거나 이를 확장하여서 또 다른 object를 생성하는 Factory를 구현하는 식으로 확장해나갈 수 있습니다.

그렇기에 Prototype 방식에서는 clone이라는 method가 굉장히 중요합니다. (또한, 이 Prototype은 Singleton이라는 것도 아시겠지요?) 기존의 abstract factory 방식과는 다르게 Factory 자체에서 Prototype을 가지고 있는 것입니다. 그리고, 이를 이용해서 object를 생성한다고 볼 수 있습니다.

이 방식은 과거 해당 책이 나오기 전까지만 해도 다소 비주류로 (물론 지금도 주류는 아닙니다.) 여겨졌었지만, 이제는 immutable이라는 말도 계속해서 사용되고 있고, Modern Java, javascript 등 여러 언어에서도 이 pattern을 기본으로 받아들였습니다.

---

여기서는 어떨까요?

이 또한 factory에게 생성을 맡겼고, product 또한 이를 대표할 수 있는 전형적인 예 정도를 알고 있다고 볼 수 있습니다. 그렇기 때문에 우리는 productA, productB라는 object가 정확하게 무엇인지도 모르고, 이를 만드는 방법 또한 모르는 상태입니다.

### 5. Factory Method

![factoryMethod](/images/factoryMethod.jpeg)

이번에는 조금 다른 구현입니다. 이번에는 생성을 위한 대리자를 두지 않고, 다른 Product를 쓰고 싶다면, App 자체를 새로 작성하자는 흐름입니다. 이렇게 하게 되면, App 자체가 특정 Product와 의존성이 생기게 됩니다. 하지만, 정확하게 Product를 알고 있다는 것은 type 검사에 시간을 낭비하지 않을 수 있다는 뜻이고, 그로 인해 더 빠른 개발이 가능하다는 뜻으로 받아들일 수 있습니다.

이 방법론은 대게 개발 초기에 매우 많이 쓰인다고 합니다. 왜냐하면, 아직 어떤 Product까지 지원할지 모르지만 어느정도의 추상화를 통해서 해당 object가 가져야 할 최소한의 기능을 지정해놓고, 바로 특정 object에 대한 개발을 시작함으로써 해당 시스템의 검증을 빠르게 수행할 수 있는 것입니다. 그리고, 후에 maintain의 시간이 오면, code를 refactoring 하고 위에서 보았던 다른 design pattern을 검토하며 선택하는 시간을 가진다고 볼 수 있습니다.

해당 시스템에 대한 구현은 제 Github에 별도의 Branch를 통해서 구현해두었습니다. 언어는 typescript로 작성하였고, 참고할 수 있으면 좋겠습니다. :)

[🔗 GitHub](https://github.com/euidong/oop-design-pattern/tree/creational-pattern)

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

[Design Pattern] 2. Creational Pattern

## Intro

점점 다양한 언어들이 생겨나고, 객체 지향에 대한 관심이 시들해지고 있는 환경이라고 생각합니다. 하지만, 그럼에도 불구하고, 여러 시스템에서도 거의 고유 명사로 쓰이고 있기에 객체 지향의 대표적인 디자인 패턴을 익혀두는 것은 필수적이라고 생각해서 제가 봤을 때 가장 빈번하게 사용되는 용어에 대해서 정리를 좀 해보고자 합니다.

해당 글에서는 일단 introduction에 대한 내용을 정리합니다.

## Design Pattern

software적으로 특정 상황에서 일반적인 문제를 해결하기 위해서 반복되어 사용되는 pattern을 말합니다. 이는 특정 문제를 해결하기 위한 algorithm이 아닌 이런 구조가 더 경험상 안정적인 구조를 이룰 수 있다는 template를 제공하는 것입니다.

이러한 pattern들은 4개의 요소를 가집니다.

1. **Pattern name** : pattern의 실제 이름을 의미합니다.
2. **Problem** : 언제 해당 pattern을 적용하는지를 표기합니다. 하나의 pattern으로 여러 문제를 해결할 수 있다면, 당연히 list 형태로도 표기합니다.
3. **Solution** : design을 이루는 요소들과 관계, 역할(책임)을 명시한다. 하나의 문제에 정확하게 대치되는 해결책을 보여주는 것이 아니라 구조를 파악할 수 있는 template를 제공합니다.
4. **Consequences** : 해당 pattern을 적용하게 되었을 때 얻게 되는 결과로, 대게 유연하게 확장이나 재사용을 할 수 있는지에 대한 관점에서 장점과 단점을 표기합니다.

이 책에서 말하는 design pattern들이 추가하는 가장 큰 목표는

Object Oriented Programming을 100% 활용할 수 있는 방법을 찾는 것입니다.

**이는 Maintainable 하기 위해서, 가독성이 높고 유연하며, 재사용이 좋은 system을 구축하기 위한 방법을 찾는 것이라는 말과 같습니다.**

이를 항상 머릿속에 두고, 이어 나갑시다.

### Example) MVC

design pattern에 대하여 이해를 돕기 위한 예시입니다. 만약, MVC 자체가 생소하다면, 넘어가는 것이 좋습니다.

가장 일반적으로 UI 작업을 하게 될 때 많이 사용되는 design pattern입니다. 이를 구성하는 Model / View / Controller의 앞 글자를 하나씩 가져와서 이를 지은 것입니다.

여기서, Model은 application의 data를 표현하는 객체입니다. 
View는 model을 user들에게 보여주는 방법을 정의한 객체입니다. 
Controller는 user input에 대하여 model 또는 view를 어떻게 변경할지를 정의한 객체입니다.

여기서, 흔히 사용되는 design pattern 3가지를 발견할 수 있습니다.

> **1. Observer pattern**

이는 model과 view를 분리하고, subscribe/notify 형태를 갖게 한 구조입니다.(view는 model의 변경이라는 event를 구독하고 있고, model은 자신이 변경되면, view에게 이를 알려서, view가 변경될 수 있도록 한다.)

이렇게 분리함으로써 얻는 효과는 우리는 하나의 model에 대해서 여러 개의 view를 가질 수 있다는 점이다. 또한, 새로운 view를 추가할 때에도 model을 변경하지 않아도 됨으로 쉽게 확장이 가능하다.

> **2. Composite pattern**

View는 중첩해서 사용이 가능하다. 즉, View안에 View를 중첩해서 쌓음으로써 재사용을 수행하는 것이다.

> **3. Strategy pattern**

View는 user input을 받는 장치(button) 등을 포함하고 있고, Controller instance를 포함하고 있기 때문에, 해당 instance를 교체함으로써 쉽게 동작을 변경하는 것도 가능하다.

### Type

해당 책에서는 총 23가지의 design pattern을 제시합니다. 그들을 분류하는 체계를 어느 정도 나눈다면 쉽게 이해가 가능할 겁니다.

> **1. Purpose**

실제로 해당 pattern이 하고자 하는 바를 나타냅니다. 총 3 가지의 목적으로 design pattern을 나눈 것이 가능합니다.

1. **Creational** : object의 생성 시에 특정 부분을 자식 class 또는 다른 object로 옮기는 방법을 제공합니다.
2. **Structural** : class 또는 object를 구조화하는 방법을 제공합니다.
3. **Behavioral** : class 또는 object가 특정 행동을 구현하기 위한 각 요소의 관계를 정의합니다.

> **2. Scope** : 구현이 기본적으로 class 단위인지, object 단위 인지를 나타냅니다.

1. **Class** : class들과 subclass들 간의 관계를 다루기 때문에, 상속에 의해서 정의되며, compile time에 고정되어서 바뀌지 않습니다.
2. **Object** : object들 간의 관계를 의미하며, run time에 유동적으로 바뀔 수 있습니다.

![design-pattern-category](/images/design-pattern-category.jpeg)

### Basic Skill

design pattern이 해결하기 위해서 사용하는 일반적인 기술들을 먼저 이해하면, 이를 조합해서 우리는 design pattern을 구성할 것이므로, 이 일반적인 기술부터 알아보고 가도록 합시다.

#### Object Oriented Programming

이 책의 가장 기본이 되는 객체 지향에 대한  내용입니다. 이를 읽고 아래를 읽으시는 것이 이해가 더 쉬울 것입니다. 이미 알고 있다면, 바로 다음부터 읽으시면 될 거 같습니다.

일반적으로 object oriented program에서 object란 data와 해당 데이터를 조작하는 여러 operation를 묶은 것을 말합니다. 이때, 우리는 해당 object 안의 data를 직접적으로는 접근할 수 없고, object에게 operation의 동작을 요청함으로써 output으로써 data를 얻거나 변경할 수 있습니다. 이를 우리는 encapsulated 되었다고 합니다.

object에 의해서 선언된 모든 operation은 이름과 input parameter, output value를 명시한 signature를 가집니다. 이러한 signature를 모아놓은 것을 해당 object의 interface라고 합니다. 따라서, interface에 있는 내용을 만족하는 request만이 object로 보내진 다고 할 수 있습니다. 여기서 중요한 것은 interface는 절대로 구현을 포함하지 않습니다. 단지 해당 operation에 대한 이름과 input, output을 알려줄 뿐입니다. 그렇기에 같은 이름이며, 들어가는 데이터, 나오는 데이터는 같지만 전혀 다른 구현을 가지도록 만들 수도 있는 것입니다. 이처럼 run time에 interface를 implementation 한 object 중에서 무엇을 실행시킬지를 선택할 수 있도록 하는 기술을 dynamic binding이라고 합니다. interface가 runtime에 정확하게 어떻게 동작할지 여러 형태를 가지는 것을 우리는 polymorphism이라고 합니다.

이 구조가 가지는 장점은 다음과 같습니다.

> **1. 대체 가능하다.**

"우리가 글을 쓰기 위해서는 반드시 연필이 필요하다."는 규칙을 정했다면,

우리는 샤프나 다른 볼펜이 있더라도 이 규칙에 어긋나므로 우리는 기존 규칙을 다시 바꾸거나 연필을 가져와야 할 것입니다.

하지만, 애초에 규칙을 "우리가 글을 쓰기 위해서는 반드시 검은색을 표시할 수 있는 도구가 필요하다."는 규칙을 정했다면, 더 유연한 규칙이 될 수 있습니다.

우리의 코드도 마찬가지로 interface를 통해서 검은색 글자를 쓰는 함수를 정의한 interface로 선언하고 이를 type으로 지정해둔다면, 이를 실행하는 object가 연필, 샤프, 볼펜 무엇이 되어도 되기 때문에 대체 가능한 구조를 가질 수 있는 것입니다.

> **2. 유연하다.**

위의 처럼 규현 할 수 있기 때문에 우리는 유연하게 구조를 만들 수 있습니다. 모든 관계가 느슨하게 연결된다고 SW 업계에서는 자주 표현합니다.

가능한 한 최소한의 기능만을 통해서만 대상을 정의한다면, 더욱더 유연한 구조가 된다고 할 수 있습니다.

> **3. 가독성이 좋다.**

우리는 해당 object를 사용할 때 이것이 어떻게 돌아가는지 모르더라도 사용할 수 있기를 바랍니다. 스마트폰을 가동시키기 위해서 이것의 부팅 절차와 여러 algorithm을 이해하는 것은 우리가 문자를 보내는 과정에서 불필요한 내용입니다. 따라서, 우리는 최대한 최소한의 내용만을 알면 됩니다. 가령 "오른쪽  전원 버튼을 누르면(input) 화면이 켜진다(output)"는 이러한 내용입니다. 이는 우리가 더 복잡한 문자 메시지 보내기를 쉽게 할 수 있는 토대를 제공합니다.

> **4. 문서화가 용이하다.**

이제 우리가 시스템을 판매하거나 이를 통해서 같이 일해야 하는 경우가 생긴다면, 이에 대한 설명서가 필요합니다. 만약, 여러 방식으로 구현을 해두었다면, 통일성 있는 문서를 기대할 수는 없습니다. 하지만, interface를 통해서 구현했다면, 이 interface가 요구하는 동작만을 정확하게 적어둔다면, 쉽게 이해할 수 있고 구조화된 문서를 만들기가 용이합니다.

그렇다면, 실제로 programming에서 이 interface와 object를 구현하는지를 살펴보아야 합니다.

대게의 언어에서는 interface, abstract class라는 것을 포함합니다. 이들을 각 각 이들을 구현 또는 상속할 대상들이 반드시 가져야 할 요소(name, input parameter, return value)에 대한 내용을 기술합니다.

그러면 우리는 class를 통해서 이에 대한 구현을 수행합니다. 따라서, 우리는 하나의 interface에 대하여 여러 개의 구현을 가지게 됩니다. (이를 구현을 defer(미루었다)고 표현합니다.) 그리고, 이제 실제로 만들어지는 object들을 우리는 class를 instantiating(틀을 기반으로 복사)하여 생성하는데 이때 만들어진 대상을 우리는 특별히 instance라고 합니다.

또한, class를 선언한다는 것은 우리에게 두 가지 효과를 불러옵니다. class라는 instantiating 하기 위한 틀을 만들 뿐만 아니라 type을 생성합니다. 즉 우리가 일반적으로 instance를 만들기 위해서 다음과 같은 과정을 거치게 될 때 앞에 있는 Class는 class의 type을 의미하는 것이고, 뒤에 있는 것은 instance를 만들기 위한 틀을 의미합니다.

```c++
SimpleClass sc = new SimpleClass();
```

그렇습니다. 만약 우리가 class를 interface의 구현으로 만든 것이 아니라면, interface type을 만들면서, class 틀까지 같이 만든 것으로 이해할 수 있는 것입니다. 하지만, interface와 다른 점이라면, 이를 상속하게 되면, 이 안의 구현도 같이 subclass로 전달된다는 점이 있겠습니다. 따라서, 우리가 더 유연한 시스템을 만들고자 한다면, 당연히 일반 class를 통해서 만들어지는 type를 사용하기보다는 abstract class 또는 interface를 통해서 만들어지는 type을 활용하는 것이 더 유연하고, reusable 한 구조를 만드는 핵심이 될 수 있습니다.

마지막으로 다룰 내용은 class의 구성 방식입니다.

만약, 특정 시스템이 무언가를 구현한다고 했을 때, "A는 B다"를 통해서 구현하는 것이 좋을까 아니면, "A는 B를 갖고 있다"를 통해서 구현하는 것이 좋을 가입니다.

일반적으로 우리는 상속을 통해서 표현되는 관계를 "inheritance" 또는 "is a" 관계라고 합니다. 즉, A가 B라는 클래스를 상속한다면, A는 B이다.라고 말할 수 있습니다. 왜냐하면, B를 상속하는 A는 당연히 B의 하위 관계이기 때문입니다. (ex. 코끼리는 동물이다.) 하지만, 상속이 아닌 변수로서 이를 포함할 때 우리는 이를 "composition" 또는 ("has" or "use") 관계라고 합니다. 즉, A가 B를 갖고 있다로 보는 것입니다. (ex. 코끼리는 동물의 속성을 가진다.)

이 중에서 어떤 식으로 구현하는 것이 유연한 구조를 만들 수 있을지는 자명합니다. 당연히 composition입니다.

이를 알아보기 위해서 구현이 바뀌는 예시를 들어봅시다.

- 만약, 코끼리 중에서 코가 짧은 개체가 발견되어 더 이상 코끼리는 코가 크다는 속성을 쓸 수 없는 경우
 - inheritance, composition : 둘 다 구현부에서 쉽게 변경이 가능합니다.
- 코끼리 중에서 외계에 존재하는 종이 발견되어 외계종의 특징을 추가해야 하는 경우
 - inheritance : 외계 생명체라는 interface를 추가로 상속합니다. 하지만, 이 과정에서 충돌되는 속성들(ex. 겹치는 operation 이름, 서로 반대되는 성질) 등에 의해서 최악의 경우 interface를 수정해야 할 수도 있습니다. 그렇게 되는 경우 이 interface를 구현한 모든 class들 역시 변경이 필요합니다
 - composition: 해당 외계 생명체라는 속성을 가져와서 필요로 하는 속성만을 확인하고 구현합니다.
- 코끼리라는 식물이 새로 발견된 경우 => 모두 크게 변경해야 함.
 - inheritance : 상속을 식물로 변경하고, 식물의 속성에 구현된 것을 새로 정의합니다.
 - composition : 가지고 있던 변수를 식물로 변경하고, 변수에 의존성이 있던 부분을 직접 바꾸어 구현합니다.

따라서, 대개의 경우 상속은 interface를 직접적으로 구현할 때에만 사용하고, 그 외에 경우에 composition을 통해서 의존성을 형성하는 것을 선호합니다.

composition은 해당 관계가 run-time에 생성되는가 아니면, compile-time에 생성되는가에 따라서 두 개로 나뉠 수 있습니다.

만약, class 내부에서 해당 변수를 생성 시부터 소멸 시까지 갖고 있는다면, 이는 aggregation(have)로 볼 수 있습니다. (즉, compile time에 관계가 형성됩니다.) 그렇지 않고, run time에 생성되어 잠깐 사용되는 정도의 관계라면, 이는 acquaintance(use) 관계로 봅니다.

#### Finding Appropriate Objects

우리가 해결하고자 하는 문제를 위해서 어느 정도까지의 object들이 필요하고, 이를 어떻게 정의할 것인지를 결정하는 것을 도와줄 수도 있습니다.(Composite, Strategy,...)

#### Determining Object Granuality

Object를 무엇으로 결정했다면, 당연히 이 Object의 크기를 어느 정도로 할지에 대한 내용도 필요하게 될 것입니다. 이를 정의하는 design pattern(Facade, FlyWeight,...)도 존재합니다.

#### Specifying Object Interfaces

무엇을 interface에 추가해야 하는지 아니면 포함시켜서는 안 되는지에 대한 내용을 서술한 design pattern(Memento), interface 간의 관계를 표현하는 것(Decorator, Proxy)도 있습니다.

#### Delegation

delegation은 자신의 operation의 구현을 composition 한 instance에게 맡기는 방식입니다.

![delegation](/images/delegation.jpeg)

보는 바와 같이 자신의 Area라는 함수의 실행을 Rectangle의 Area 함수로 대체함으로써 더 유연한 구조를 만들 수 있습니다. 만약에 Window가 Circle로 바뀐다면 간단히 Circle의 instance를 생성해서 이 instance의 Area를 호출하도록 하면 될 것입니다.

이는 굉장히 유용하고, 유연한 개발이 가능하지만, 다른 instance의 요소를 실행시키니 만큼 run-time 중에 비효율적인 동작을 막을 수는 없습니다. 따라서, 이를 유의하고 사용해야 합니다.

실제로도 State, Strategy pattern에서도 사용됩니다.

## Reference

- Design Patterns: Elements of reusable object oriented software.
- Thumbnail : Photo by [MagicPattern](https://unsplash.com/es/@magicpattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/design-pattern?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)