디자인패턴의 개요
태그 :
- 개념
- 디자인패턴 - 소프트웨어 설계에서 얻은 세세한 경험들을 기록해 놓도록 하는 것임 - 각각의 다지인 패턴은 기존 환경 내에서 반복적으로 일어나는 문제들을 설명하고, 그 문제들에 대한 해법의 핵심을 설명하는 것임(이렇게 하면 똑 같은 문제가 반복하지 않고 백만 번 이상 재사용이 가능함) - 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조로부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화 한 것 것임
I. 디자인패턴의 정의
- 소프트웨어 설계에서 얻은 세세한 경험들을 기록해 놓도록 하는 것임
- 각각의 다지인 패턴은 기존 환경 내에서 반복적으로 일어나는 문제들을 설명하고, 그 문제들에 대한 해법의 핵심을 설명하는 것임(이렇게 하면 똑 같은 문제가 반복하지 않고 백만 번 이상 재사용이 가능함)
- 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조로부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화 한 것
II. 디자인패턴의 목적
- 설계자로 하여금 재사용을 가능하게 하는 설계를 선택하게 하고 재사용을 방해하는 설계는 배제하도록 함, 즉 ‘올바른’ 설계를 빨리 만들 수 있도록 도와줌
III. 패턴의 네 가지 요소(이문해결)
1) 패턴 이름(Name) : 설계 문제와 해법을 서술
2) 문제(Problem) : 해결할 문제와 그 배경을 설명함
3) 해법(Solution) : 설계를 구성하는 요소들과 그 요소들 간의 관계, 책임 그리고 협력관계를 서술함
4) 결과(Consequences) : 디자인 패턴을 적용해서 얻는 결과와 장단점을 서술
IV. 디자인패턴의 원칙
|
원칙 |
내용 |
|
캡슐화 |
바뀌는 부분은 캡슐화 |
|
위임 |
상속보다는 위임을 활용 |
|
인터페이스 |
구현이 아닌 인터페이스에 맞춰서 프로그래밍 |
|
Loosely Coupling |
서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 사용 |
|
개방 & 폐쇄 |
클래스 확장에 대해서는 OPEN, 변경에 대해서는 CLOSE |
|
의존관계 |
추상화된 클래스에 의존하고 구현 클래스 의존은 배제 |
V. 디자인패턴과 프레임웍크와 3가지 차이점
1) 디자인 패턴이 프레임워크 보다는 더 추상적
. 프레임워크는 구현을정의, 디자인패턴은 예만 코드로 작성
2) 디자인 패턴은 프레임워크에 비해 소규모 아키텍처 요소임
. 일반적으로 프레임웍크는 여러 디자인 패턴을 포함하지만, 디자인 패턴은 프레임웍크를 포함하지 않음
3) 디자인 패턴은 프레임워크보다 구체적이지 않음. 프레임워크는 어떤 특정 어플리케이션을 목표로 함
VI. 분류와 종류
1) 객체생성 패턴
- 객체 인스턴스 생성을 위한 패턴으로, 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴이다. 클래스 정의와 객체 생성 방식을 구조화, 캡슐화한 방법을 제시한다.
2) 구조개선 패턴
- 다른 기능을 가진 객체가 협력을 통해 어떤 역할을 수행할 때, 객체를 조직화시키는 일반적인 방식을 제시한다.
- 별도로 구성된 클래스 라이브러리를 통합하는 데 유용하다.
- 생성패턴과 달리 새로운 기능을 구현하기 위해 객체를 구성하는 방식 자체에 초첨이 맞춰져 있다.
3) 행위개선 패턴
- 객체의 행위를 조직화, 관리, 연합하는데 사용되는 패턴이다.
- 객체간의 기능을 배분하는 일과 같은 알고리즘 수행에 주로 이용된다.
- 단지 객체나 클래스에 대한 유형을 정의하는 것이 아니라 그들 간의 연동에 대한 유형을 제시한다.
VII. 디자인패턴의 형식
|
구분 |
내용 |
|
패턴명 |
패턴 자체의 내용을 효과적으로 전달할 수 있는 이름 |
|
유형Classification) |
여러 개의 패턴을 체계적으로 분류 - 생성(Creational): 객체들의 생성과 관련된 패턴 - 구조(Structure): 클래스, 객체의 정적인 구조와 관련된 패턴 - 행위(Behavioral): 클래스와 객체의 반응과 책임 할당 |
|
목적 |
이 패턴이 무엇을 하며 어떤 의도로 작성되었는지 무엇을 해결하는지를 설명하여 기술 |
|
별칭 |
위의 공식적인 이름 외에 잘 알려진 다른 명칭 |
|
구조Structure) |
패턴 안에서 문제를 해결하기 위해 사용되는 클래스와 객체의 구조를 UML 다이어그램으로 표현 |
|
구성요소 |
구조항목에 포함된 각종 클래스, 객체의 의미와 그 책임을 설명 |
|
협력과정 |
각 클래스와 객체가 자신에게 맡겨진 책임을 수행하기 위해 서로 메시지를 주고 받는 과정을 묘사 |
|
구현 |
패턴을 구현할 때 고려사항과 힌트, 함정, 방법, 프로그래밍 언어별 주의할 점등을 기술함 |
|
샘플코드 |
특정 언어로 패턴을 구현한 예제, 실제로 사용되는 시스템에서 발견되는 패턴의 예제 |
|
솔루션 |
패턴이 목적을 달성하기 위해 어떤 면을 해결하는지 설명하고 패턴을 적용한 때 발생할 수 있는 문제점과 패턴 적용시 효과 등을 기술 |
|
관련 패턴 |
본 패턴과 유사하거나 밀접하게 관련된 다른 패턴 |
- 디자인패턴과 프레임워크과 아키텍처
|
구분 |
디자인패턴 |
아키텍처 |
프레임워크 |
|
목적 |
- 실제 구현 과정에서 해결방안으로 제시 |
- 전체 시스템의 구조나 설계모형 재사용 |
- 시스템 구현효율성 향상과 개발편의성 제공 |
|
범위 |
- 모든 구현 과정 중 일관된 문제에 적용 |
- 모든 종류의 시스템에 적용 가능 |
- 하나의 시스템을 구축하기 위한 틀 |
|
효과 |
- 유지보수의 용의성, 이해하기 쉬운 코드로 단순화 가능 - 문제에 대한 패턴 인식하여, 일치하는 디자인 패턴을 찾아 프로젝트에 적용 - 어플리케이션의 확장성 향상, 비즈니스 요구 사항 변화에 적시대응 - 어떤 문제점에 대한 해결안 찾는 시간과 개발기간 단축 |
- 구체적인 코드와 함께 요구변경이나 다른 제약 조건 등에 대한 대응 방안이 다름 - 구현경험 이해로 바람직한 아키텍처 설계 가능 - 구조도로서의 이해와 실제 설계작업 중 각 구현상 특징 별 구체적인 코딩방안까지 설계할 수 있어야 함 |
- class library로 프로젝트 의 일부를 갖고 있음 - 정해진 설계 방식에 따라 실제 코드가 일부 작성, 프레임워크 클래스를 서브 클래싱 해서 유저 코드 작성 - 프레임워크 코드가 유저코드 호출 방식 - 실행 흐름을 프레임 워크가 제어 - 객체의 연동은 구조 프레임워크가 정의 |
- GoF의 23개 디자인 패턴
|
디자인패턴 영역 |
목적 |
|||
|
생성 |
구조 |
행위 |
||
|
범위 |
클래스 |
Factory method:인스턴스화될 객체의 서브클래스 |
Adaptor: 객체 인터페이스 |
Interpreter:언어의 문법과 해석방법 Template Method:알고리즘 단계 |
|
객체 |
Abstract Factory: 제품객체군 Builder: 복합 객체 생성 Prototype: 인스턴스화될 객체 클래스 Singleton: 인스턴스가 하나일 때 |
Adaptor Bridge: 객체 구현 Composite:객체의 합성과 구조 Decorator:서브클래싱 없이 객체의 책임성 Façade:서브시스템에 대한 인터페이스 Flyweight:객체 저장 비용 Proxy: 객체 접근방법 |
Chain of Responsibility:요청처리객체 Command:요청 처리 시점과 방법 Iterator:집합객체 요소 접근/순회방법 Mediator: 객체 상호 작용 Memento: 객체정보 외부 저장 Observer: 종속객체 상태 변경 State: 객체 상태 Strategy:알고리즘 Visitor:클래스변경없이 객체에 적용할 수 있는 오퍼레이션 |
|