01. 디자인패턴
특정 문맥에서 공통적으로 발생하는 문제에 대해 사용되는 재사용 가능한 해결책
목적별로 일정한 형태의 패턴이 제시되어 있다.
GoF에서 제시한 대표적인 23개의 패턴을 상황에 적합하게 결정하여 사용하는 것이 좋다.
02. 디자인 패턴의 장단점
장점
- 소프트웨어 구조 파악이 용이하다.
- 재사용성이 높아 개발 시간 단축 가능.
- 설계 변경에 비교적 유연하게 대처 가능.
단점
- 객체지향적 설계를 고려하여 진행.
- 초기 비용이 높다.
- 복잡성
- 세상에 만능은 없다적절하게 사용하지 않으면 불필요하게 어렵고 복잡해진다.
03. 목적에 따른 분류
03.1 생성 패턴
특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 최소화
| 패턴 | 설명 |
|---|---|
| Abstract Factory | 구체적인 클래스를 지정하지 않고 인터페이스를 통해 연관 객체를 묶어줌 |
| Factory Method | 객체 생성을 서브 클래스에 위임(캡슐화) |
| Singleton | 단일 인스턴스를 보장하는 패턴 |
| Builder | 생성과 표현을 분리하여 단계별로 생성하는 패턴 |
| Prototype | 원본 객체를 복사하여 새 객체를 생성하는 패턴 |
03.2 구조 패턴
시스템 내, 자료 구조나 인터페이스 구조 등 프로그램 구조를 설계하는데 사용되는 패턴
| 패턴 | 설명 |
|---|---|
| Adapter | 클래스의 인터페이스를 다른 인터페이스로 변환 |
| Bridge | 구현부에서 추상화를 분리하여 각자 독립적으로 변형 및 확장할 수 있게 함. |
| Composite | 객체들을 관계를 트리 구조로 구성하여 표현 |
| Decorator | 객체에 동적으로 책임 추가(객체에 다른 객체를 붙임) |
| Facade | 서브 시스템에 대해 단순한 통합된 인터페이스 제공 |
| Flyweight | 크기가 작은 여러 객체들을 최대한 공유하여 메모리 절약 |
| Proxy | 다른 객체를 대신하여 흐름 제어 |
03.3 행동 패턴
반복적으로 사용되는 객체들의 커뮤니케이션을 패턴화
결합도를 최소화하는것이 주 목적
| 패턴 | 설명 |
|---|---|
| Chain of Responsibility | 요청을 처리하는 객체를 만날때까지 Chain을 따라 요청을 전달 |
| Command | 요청을 객체의 형태로 캡슐화하여 재사용 또는 취소 지원 |
| Interpreter | 특정 언어의 문법 표현을 정의 |
| Iterator | 내부 구현을 노출하지 않으며 각 항목에 접근할 수 있는 방법 제공 |
| Mediator | 객체들 사이의 직접적인 연결을 최소화하여 객체 간의 유연한 관계를 촉진 |
| Memento | 객체가 특정 상태로 되돌아 올 수 있도록 내부 상태를 실체화 |
| Observer | 객체 상태가 변할 때 관련 객체들이 변화를 전달받아 갱신 |
| State | 객체의 상태에 따라 동일한 동작을 다르게 처리 |
| Strategy | 알고리즘을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 함 |
| Template Method | 상위 클래스는 틀만 작성하고, 구체적인 처리는 서브 클래스로 위임 |
| Visitor | 객체의 원소에 대해 수행할 연산을 분리하여, 구조 변경없이 새로운 연산 정의 가능 |
