Design Pattern (1)

[패턴을 사용하는 이유]

1. 재사용 가능한 소프트웨어

2. 과거의 솔루션을 재사용

3. 잘 구조화된 시스템 재사용

4. 어떤 언어든지 용이한 대화가 가능

 

 

[디자인 패턴의 세가지 룰]

1. Context
2. Problem

3. Solution

 

[Design Pattern : Iterator]

1. Context - 어떤 객체의 collection

2. Problem - collection을 순회하고 싶다. 그대신 collection의 구조는 보이지 않는채로

3. Solution - iteration을 캡슐화

=> iteration에서 사용되는 api는 공통으로 구현하고 그 내부는 동작을 따로 구현

 

[GoF Pattern]

		Purpose
		Creational	Structural	Behavioral
Scope	Class	Factory Method	Adapter	Template
	Object	Abstract Factory Builder Singleton	Adapter Bridge Composite Decorator	Iterator Mediator Observer State Strategy

[Creational]

- 유연하게 클래스를 생성

- 생성하는 과정을 분리

 

[Structural]

- 상속을 통해 클래스를 조직화

 

[Behavioral]

- 어떤 클래스에게 책임을 줄지 결정

- 클래스들 간의 static 한 관계 commuication을 어떻게 하는지에 따라 결정

 

[Key feature of Design Patter]

Patteren name	패턴에 알맞는 이름을 지어야 한다
Intent	패턴의 의도
Problem	패턴이 적용될 수 있는 문제
Solution	추상적인 설명 / 클래스간의 관계, 역할
Consequences	패턴의 장점, 단점이 존재
Implementation	패턴이 어떻게 구현되는지
Generic structure	다이어그램을 사용한 패턴의 일반적인 구조

 

[Level of Patterns [POSA]]

1. Architectural pattern

- 소프트웨어의 구조적인 조직, 구조

- 시스템 전체에 대한 골격, 조직

 

2. Design pattern

- sub system, component, relationship를 재사용

- 전체 시스템에 영향을 미치지는 않음

 

3. Coding pattern 

- 특정한 프로그래밍 언어의 패턴