[Chapter1] 디자인패턴이란?

0. 시작하기

 설계는 지금 당장 갖고 있는 문제를 해결할 수 있어야 하지만, 나중에 생길 수 있는 문제나 추가된 요구 사항들도 수용할 수 있도록 일반적이고 포괄적이어야 합니다. 즉, 재설계를 하지 않아도 다시 사용할 수 있어야 하고, 아니면 가능한 최소한의 수정을 통해서 다시 사용할 수 있는 설계여야 합니다.

1. 디자인 패턴이란?

 디자인 패턴은 "특정한 전후 관계에서 일반적 설계 문제를 해결하기 위해 상호교류하는 수정 가능한 객체와 클래스들에 대한 설명"입니다.

 디자인 패턴은 설계자로 하여금 재사용이 가능한 설계는 선택하고, 재사용을 방해하는 설계는 배제하도록 도와주며, 패턴을 쓰면 이미 만든 시스템의 유지보수나 문서화도 개선할 수 있고, 클래스의 명세도 정확하게 할 수 있으며, 객체 간의 상호작용 또는 설계의 의도 등까지 명확하게 정의할 수 있습니다.

▷  생성 패턴은 객체의 생성 과정에 관여하는 것

- 생성 클래스 패턴은 객체를 생성하는 책임의 일부를 서브클래스가 담당

- 생성 객체 패턴은 이를 다른 객체에게 위임.

▷ 구조 패턴은 클래스나 객체의 합성에 관한 것

- 구조 클래스 패턴은 상속을 이용해서 클래스를 복합

- 구조 객체 패턴은 객체를 합성하는 방법을 정의

▷ 행동 패턴은 클래스나 객체들의 상호작용하는 방법과 책임을 분산하는 방법을 정의

- 행동 클래스 패턴은 상속을 이용해서 알고리즘과 제어 흐름을 기술

- 행동 객체 패턴은 하나의 작업을 수행하기 위해 객체 집합이 어떻게 협력하는지를 기술

		목적
		생성	구조	행동
범위	클래스	팩토리 메서드 (Factory Method)	적응자(Adapter class)	해석자(Interpreter) 템플릿 메서드 (Template Method)
	객체	추상 팩토리(Abstract Factory) 빌더(Builder) 원형() 단일체	적응자(Adapter object) 가교(Bridge) 복합체(Composite) 장식자(Decorator) 퍼사드(Facade) 플라이급(Flyweight) 프록시(Proxy)	책임 연쇄 (Chain of Responsibilty) 명령(Command) 해석자(Interpreter) 중재자(Mediator) 반복자(Iterator) 메멘토(Memento) 감시자(Observer) 상태(State) 전략(Strategy) 방문자(Visitor)

<표1> 디자인 패턴 영역

<그림 1> 디자인 패턴 관계도

2. 디자인 패턴이 필요한 이유?

1) 특정 클래스에서 객체 생성

 객체를 생성할 때 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속됩니다. 이런 종속은 앞으로의 변화를 수용하지 못합니다. 이를 방지하려면 객체를 직접 생성해서는 안됩니다.

(디자인 패턴 : 추상 팩토리, 팩토리 메서드, 원형)

2) 특정 연산에 대한 의존성

 특정한 연산을 사용하면, 요청을 만족하는 한 가지 방법에만 매이게 됩니다. 요청의 처리 방법을 직접 코딩하는 방법을 피하면, 컴파일 시점과 런타임 모두를 만좃하면서 요청 처리 방법을 쉽게 변경할 수 있습니다.

(디자인 패턴 : 책임 연쇄, 명령)

3) 하드웨어와 소프트웨어 플랫폼에 대한 의존성

 기존에 존재하는 시스템 인터페이스와 응용프로그래램 프로그래밍 인터페이스는 소프트웨어 및 하드웨어 플랫폼마다 모두 다릅니다. 특정 플랫폼에 종속된 소프트웨어는 다른 플랫폼에 이식하기도 어렵고요. 또한 본래의 플랫폼에서도 버전의 변경을 따라가기 어려울 수 도 있습니다. 이런 플랫폼 종속성을 제거하는 것은 시스템 설계에 있어 매우 중요합니다,.

(디자인 패턴 : 추상 팩토리, 가교)

4) 객체의 표현이나 구현에 대한 의존성

 사용자가 객체의 표현 방법, 저장 방법, 구현 방법, 존재의 위치에 대한 모든 방법을 알고 있다면 객체를 변경할 때 사용자도 함"께 변경해야 합니다. 이런 정보를 사용자에게 감춤으로써 변화의 파급을 막을 수 있습니다.

(디자인 패턴 : 추상 팩토리, 가교, 메멘토, 프록시)

5) 알고리즘 의존성

 알고리즘 자체를 확장할 수도, 최적화할 수도, 다른 것으로 대체할 수도 있는데, 알고리즘에 종속된 객체라면 알고리즘이 변할 때마다 객체도 변경해야 합니다. 그러므로 변경이 가능한 알고리즘은 분리해 내는 것이 바람직합니다.

(디자인 패턴 : 빌더, 반복자, 전략, 템플리 메서드, 방문자)

6) 높은 결합도

 높은 결합도를 갖는 클래스들은 독립적으로 재사용하기 어렵습니다. 높은 결합도를 갖데 되면 하나의 커다란 시스템이 되어 버립니다. 이렇게 되면 클래스 하나르 수정하기 위해서 전체를 이해해야 하고 다른 많은 클래스도 변경해야 합니다. 또한 시스템은 배우기도 힘들고, 이식은 커녕 유지보수하기 조차도 어려운 공룡이 되어 버립니다.

 약한 결합도는 클래스 자체의 재사용을 가능하게 하고 시스템의 이해와 수정, 확장이 용이해서 이식성을 증대시킵니다. 추상 클래스 수준에서 결합도를 정희한다거나 계층화시키는 방법으로 디자인 패턴은 낮은 결합도의 시스템을 만들도록 합니다.

(디자인 패턴 : 추상 팩토리, 가교, 책임 연쇄, 명령, 퍼사드, 중재자, 감시자)

7) 서브 클래싱을 통한 기능 확장

 객체 합성과 위임은 행동 조합을 위한 상속보다 훨씬 유연한 방법입니다. 기존 객체들을 새로운 방식으로 조합함으로써 새로운 서브클래스를 정의하지 않고도 응용프로그램에 새로운 기능성을 추가할 수 있습니다. 한편, 객체 합성을 많이 사용한 시스템은 이해하기가 어려워집니다. 많은 디자인 패턴에서는 그냥 서브클래스를 정의하고 다른 인스턴스와 새로 정의한 클래스의 인스턴스를 합성해서 기능을 재정의하는 방법을 도입합니다.

(디자인 패턴 : 가교, 책임 연쇄, 장식자, 감시자 , 전력)

8) 클래스 변경이 편하지 못한 점

 가끔 클래스를 변경하는 작업이 그렇게 단순하지 않을 때가 많습니다. 소스 코드가 필요한데 없다고 가정해 봅시다. 또한 어떤 변경을 하면 기존 서브클래스의 다수를 수정해야 한다고 가정합시다. 디자인 패턴은 이런 환경에서 클래스를 수정하는 방법을 제시합니다.

(디자인 패턴 : 적응자, 장식자, 방문자)

3. 디자인 패턴을 고르는 방법

- 패턴이 어떻게 문재를 해결하는지 파악합시다.

- 패턴의 의도 부분을 봅시다.

- 패턴들 간의 관련성을 파악합시다.

- 비슷한 목적의 패턴들을 모사어 공부합시다.

- 재설꼐의 원인을 파악합시다.

- 설계에서 가변성을 가져야 하는 부분이 무엇인지 파악합시다.

4. 디자인 패턴을 통해 다양화 할 수 있는 설계 측면

목적	디자인 패턴	이 패턴을 통해 다양화 할 수 있는 부분
생성	추상 팩토리 (Abstract Factory)	제품 객체군
	빌더(Builder)	복합 객체 생성 방법
	팩초리 메서드(Factory Method)	인스턴스화 될 객체의 서브클래스
	원형(Prototype)	인스턴스화 될 객체의 클래스
	단일체(Singleton)	클래스의 인스턴스가 하나일 때
구조	적응자(Adapter)	객체에 대한 인터페이스
	가교(Bridge)	객체 구현
	복합체(Composite)	객체의 합성과 구조
	장식자(Decorator)	서브클래싱 없이 객체의 책임성
	퍼사드(Facade)	서브시스템에 대한 인터페이스
	플라이급(Flyweight)	객체의 저장 비용
	프록시(Proxy)	객체 접근 비용
행동	책임 연쇄(Chain of Responsibility)	요청을 처리하는 객체
	명령(Command)	요청을 처리 시점과 처리 방법
	해석자(Interpreter)	언어의 문법과 해석 방법
	반복자(Iterator)	집합 객체 요소들의 접근 방법 및 순회 방법
	중재자(Mediator)	어떤 객체들이 어떻게 상호작용하는지
	메멘토(Memento)	어제 어떤 정보를 객체의 외부에 저장하는지
	감시자(Observer)	다른 객체의 종속적인 객체 수  종속적인 객체들의 상태 변경 방법
	상태(State)	객체의 상태
	전략(Strategy)	알고리즘
	템플릿 메소드(Template Method)	알고리즘 단계
	방문자(Visitor)	클래스의 변경 없이 객체에 적용할 수 있는 연산

<표2> 디자인 패턴을 통해 다양화 할 수 있는 설계 측면