Creational Design Patterns
Creational design patterns는 코드의 재사용성과 유연성을 높이는 다양한 객체 생성 방법을 의미한다.
- Factory Method
슈퍼클래스에서 객체를 생성하기 위한 인터페이스 제공. 서브클래스가 생성될 객체의 유형 변경 가능.
Abstract Factory
구체적인 클래스의 명시 없이 관계 된 families를 생산할 수 있도록 만드는 생성 패턴.
- Builder
빌더 패턴은 복잡한 객체를 단계별로 construct할 수 있는 패턴이다.
Prototype
객체를 복사할 때 인스턴스를 만드는 절차를 추상화 하는 패턴.
Singleton
Singleton은 이름에서 알 수 있듯이, 객체의 생성을 단 한 번으로 제한하는 것을 보증하는 패턴.
Structural Design Patterns
Structural Design Patterns는 구조체들의 유연성과 효율성을 유지하면서 어떻게 더 큰 구조체로 객체와 클래스들을 모으는지 설명한다.
- Adapter
호환되지 않는 인터페이스를 가진 객체가 협업할 수 있도록 하는 구조적 디자인 패턴.
Bridge
큰 규모의 클래스를 각자 독립적으로 개발할 수 있는 두 개의 개별 계층으로 분할할 수 있는 구조적 디자인 패턴.
- Composite
그룹 전체와 개별 객체를 동일하게 처리할 수 있는 패턴.
Decorator
객체의 결합을 통해 기능을 동적으로 유연하게 확장 할 수 있는 패턴. 기본 기능에 추가할 수 있는 기능이 많을 수록 효율 증가.
기능에 관계없이 Display를 통한 기능 추가 가능. - Facade
라이브러리, 프레임워크, 복잡한 클래스들에 대해 간략화된 인터페이스를 제공하는 패턴.
영화를 보고자 할 때, tv 켜기 → 영화 찾기 → 영화 틀기 → ... → tv 끄기 등의 많은 과정들을 영화 보기라는 기능에 축약.
- Flyweight
각 객체의 모든 데이터를 유지하는 대신 공통 되는 부분의 메모리를 공유함으로 더 많은 객체를 넣을 수 있도록 하는 패턴.
ex ) FPS 게임에서 화면에 수많은 총알을 그려야 할 때, 총알 1개마다 객체를 생성할 필요는 없다. 같은 색상, 같은 모양의 총알이라면 객체는 1개만 생성 가능
- Proxy
원본 객체를 대리하여 대신 처리하는 객체를 만드는 패턴.
Proxy 객체에 Service 내장하여 Client 는 프록시를 통해 기능 사용 가능.
- Proxy
Behavioral Patterns
Behavioral Patterns는 객체 사이의 책임 할당과 알고리즘과 관련이 있다.
- Chain of Responsibility
클라이언트의 요청에 대한 세세한 처리를 하나의 객체가 하는 것이 아닌, 여러개의 처리 객체들로 나누고, 이들을 사슬 처럼 연결해 집합 안에서 연쇄적으로 처리하는 패턴.
지원 센터 전화 시 자동응답기에서 처리할 수 없으면 상담사에게 연결, 상담사가 해결할 수 없으면 엔지니어에게 연결, 마지막으로 엔지니어가 해결하는 과정을 겪게 된다.
이와 같이 Handler가 요청을 받고 처리할 수 없으면 다음 Handler에게 넘기는 것.
- Command
요청을 요청에 대한 모든 정보가 포함된 독립형 개체로 바꾸는 디자인 패턴. 실행 될 기능을 캡슐화 함으로 재사용성이 높은 클래스 설계.
Iterator
collection을 구성하는 표현 없이 elements들을 탐색하는 요소. (java iterator?)
Mediator
복잡한 의존관계를 가지는 객체들 사이에서 직접적인 통신은 제한하고, meditator 객체를 통한 통신으로 강제하는 패턴.
문제 상황
해결 상황
- Memento
세부 사항을 공개하지 않고 객체의 이전 상황을 저장하고 복원하는 패턴. (되돌리기)
문제 상황
객체를 그대로 복사하려 하니 private field라 못하고 public으로 바꾸면 안전하지 않음.
해결
특정 상태의 snapshot인 memento 객체를 만들어서 caretaker를 통해 memento를 관리한다. - Observer
객체에서 발생하는 모든 이벤트에 대해서 관찰 중인 여러 객체에 알리는 구독 메커니즘을 정의하는 패턴.
State
객체 내부 상태에 따라 스스로 행동을 변경할 수 있게 하는 패턴 → 클래스를 바꾸는 것 처럼 보임.
Context 에 State를 넣어놓고 State에 따라 dothis()를 실행하는 방식으로 행동 방식을 바꿈.
ex ) 티켓 자판기 → 자판기는 두 개의 상태를 가짐
a. 동전이 없는 상태 → 동전 투입 시 동전 투입 상태로 바뀜, 티켓 출력 시 상태 변경 x
b. 동전이 투입 된 상태 → 티켓 출력 시 티켓 발급 후 동전 없는 상태로 바뀜. 동전을 더 넣어도 상태는 바뀌지 않는다.
→ 동전 투입, 티켓 출력과 같은 공통적인 기능이 있지만 state에 따라 행동이 다름. - Strategy
여러 알고리즘을 정의하고 각 알고리즘을 별도의 클래스에 배치하여 객체를 상호 교환 가능하게 만드는 패턴.
Navigator에는 구현체가 아닌 Interface로 추상화 된 클래스를 넣어놓고 각 Strategy를 선택해서 사용하게 됨. - Template Method
알고리즘의 구조를 메소드에 정의하고, 하위 클래스에서 알고리즘 구조의 변경없이 알고리즘을 재정의. → 중복코드 줄일 수 있음.
- Visitor
방문자와 방문 공간을 분리하여 방문 공간이 방문자를 맞이할 때, 이후에 대한 행동을 방문자에게 위임하는 패턴.
ConcreteElement 객체들에서 accpet에 방문을 받을 때 ConcreteVisitor visit 함수로 Element를 넘겨 행동을 위임.