1. 자주 사용하는 설계 형태를 정형화 해 이를 유형별로 설계 템플릿을 만들어 둔 것
2. 많은 개발자들이 경험상 체득한 설계 지식을 검증하고 이를 추상화하여 일반화한 템플릿
3. 동일한 문제 유형에 대해서 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충붕히 일반화 된것
장점:
-개발자 간의 원활한 의사소통
-소프트웨어 구조 파악 용이
-재사용을 통한 개발 시간 단축
-설계 변경 오청에 대한 유연한 대처
단점
-객체지향 설계 / 구현 위주
-초기 투자 비용 부담
명세 형식
| 이름 | 패턴은 이름과 타입을 가짐. 패턴의 타입은 생성, 구조, 행위 패턴으로 나뉜다 |
| 배경, 문제 | 패턴이 적용되는 상황 또는 다루려는 문제를 간단히 설명 |
| 솔루션 | 패턴의 구조적인 설계나 행위적인 설계를 기술. UML의 클래스 다이어그램이나 시퀀스 다이어그램으로 패턴에 참ㅇ여하는 각 클래스의 역할과 관계를 나타냄 |
| 혜택과 책임 | 패턴을 적용함으로써 얻는 이점과 잠재적인 문제점을 나타냄 |
| 가이드라인 | 패턴을 적용할 때 유용한 정보를 제공 |
| 관련 패턴 | 유사한 패턴이나 연관된 패턴을 제공하여 변형 또는 확장할 때 참고하도록 함 |
GOF의 디자인 패턴 구분
| 생성 패턴 | 기능 | 객체 생성 과정에 관한 패턴 | |
| 종류 | Factory Method Singleton Prorotype |
Builder Abstract Factory |
|
| 구조 패턴 | 기능 | 클래스나 객체의 합성에 관한 패턴 | |
| 종류 | Adapter Composite Bridge Decorator |
Facade Flyweight Proxy |
|
| 행위 패턴 | 기능 | 클래스나 객체듫이 상호작용하는 방법과 책임 분산 방법 정의 | |
| 종류 | Template Method Interpreter Iterator Observer Strategy Visitor |
Chain of Responsibility Command Mediator State Memento |
|
생성 패턴
Factory Method
1. factory: 인스턴스를 만드는 곳
2. 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식.
-객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할지 알 수 없을 때, 객체 생성을 하위 클래스에 위임하여 해결
Singleton
특정 클래스의 객체가 오직 한 개만 존재하도록 보장, 즉 클래스의 객체를 하나로 제한
-프로그래머의 '주의'에 의해서가 아닌 프로그램의 '보증'
동일한 자원이나 데이터를 처리하는 객체가 불필요하게 여러 개 만들어질 필요가 없는 경우에 주로 사용 한다.
Abstract Factory
. -추상적인 부품을 조합해 추상적인 제품을 만든다
-부품의 구체적인 구현은 제외하고 인터페이스 (API)만을 이용해 부품을 조립하고 제춤으로 완성
구조 패턴(Composite pattern)
composite object:
-부분-전체의 구조로 표현되는 조립 객체,
-사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한 것
-재귀적 구조: 디렉토리 안에 파일 또는 다른 디렉토리(서브 디렉토리)가 존재할 수 있는 것
-디렉토리(그릇)와 파일(내용물)을 동일시해서 재귀적인 구조를 만들기 위한 설계 패턴
leaf: 내부에 다른 것을 포함할 수 없는 클래스(내용물에 해당)
Composite: Leaf나 다른 Composite을 넣을 수 있는 클래스
Component: Leaf와 Composite을 동일하게 취급할 수 있도록 하는 공통적인 상위 클래스
adapter pattern
-기존 클래스를 재사용할 수 있도록 중간에서 맞춰주를 역할
-호환성이 없는 기종 클래스의 인터페이스를 변환해 사용할 수 있도록 해준다
*instance adapter pattern의 경우 composite한 객체의 메서드 overriding불가
- class adapter pattern
- instance adapter pattern
Decorator patter
-기능 확장이 필요할 때 상속의 대안으로 사용, 메서드 호출의 반환값에 변화를 주기 위해 중간에 decorator를 두는 패턴
Facade patter
-몇 개의 클라이언트 클래스와 서브시스템의 클라이언트 사이에 facade라는 객체를 둬서 복잡한 관계를 정리(구조화)한 것
-모든 관계가 전면에 세워진 facade객체를 통해서만 이뤄질 수 있게 단순한 인터페이스를 제공하는 것
- 의존도가 낮아진다.
- 다음과 같은 효과가 필요할 때 사용한다.
1. 복잡한 서브 시스템에 대해서 단순한 인터페이스가 필요할 때
2. 서브 시스템에 대해 계층화가 필요할 때
3. 서브시스템의 변경에 영향을 받고 싶지 않을때
Proxy pattern
. -제어 흐름을 조정하기 위한 목적으로 중간에 대리자를 두는 패턴
- decoration pattern과 비슷한거 같으니 decoration pattern은 기능의 확장을 위해 사용하고 proxy pattern은 단순히 흐름 조정을 위해 사용한다.
행위 패턴
Observer patter
- 어떤 클래스에 변화가 일어났을 때 이를 감지해 다른 클래스에 통보하는 것
strategy pattern
. -다른 방법으로 문제를 해결할 수 있는 알고리즘으로 쉽게 교체할 수 있게 도와준다.
-strategy: 전략 메서드를 가신 전략 객체
-context: 전략 객체의 사용자/소비자
Template Method
-상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴
Mediator patter
- 다수의 객체들 사이에 다수의 관계가 존재할 때 중재자 역할의 객체를 이용해 관계를 축소 시키는 패턴
