1. 디자인 패턴이 필요한 이유
- 특정 클래스에서 객체 생성
- 객체를 생성할 때 클래스 이름을 명시하면 어떤 특정 인터페이스가 아닌 어떤 특정 구현에 종속
- 이런 종속은 앞으로의 변화를 수용 못 함
- 객체를 직접 생성해서는 안됨
(디자인 패턴 : Abstract factory, Factory method, Prototype)
- 특정 연산에 대한 의존성
- 특정한 연산을 사용하면, 요청을 만족하는 한 가지 방법에만 의존
- 직접 코딩하는 방법을 피하면, 컴파일 시점과 런타임 모두를 만족, 요청 처리 방법을 쉽게 변경
(디자인 패턴 : Chain of responsibility, Command)
- 하드웨어와 소프트웨어 플랫폼에 대한 의존성
- Windows, Unix, iOS, etc
(디자인 패턴 : Abstract factory, Bridge)
- 객체의 표현이나 구현에 대한 의존성
- 객체의 표현 방법, 저장 방법, 구현 방법, 존재의 위치 등알고 있다면 객체를 변경시 사용자도 함께 변경
- 이런 정보를 사용자에게 감춤으로써 변화 변경 못함
(디자인 패턴 : Abstract factory, Bridge, Memento, Proxy)
- 알고리즘 의존성
- 알고리즘 자체를 확장할 수도, 최적화할 수도, 다른 것으로 대체
- 알고리즘에 종속된 객체라면 알고리즘이 변할 때마다 객체도 변경
- 변경이 가능한 알고리즘은 분리
(디자인 패턴 : Builder, Iterator, Command, Template method, Visitor)
- 높은 결합도
- 높은 결합도를 갖는 클래스들은 독립적으로 재사용 불가
- 시스템은 배우기도 힘듦
- 이식은 커녕 유지보수하기 조차도 어려움
- 약한 결합도는 클래스 자체의 재사용을 가능
- 시스템의 이해와 수정, 확장이 용이해서 이식성을 증대
- 추상 클래스 수준에서 결합도를 정의
- 디자인 패턴은 낮은 결합도의 시스템을 만듦
(디자인 패턴 : Abstract factory, Bridge, Chain of responsibility, Command, Facade, Mediator, Observer)
- 서브 클래싱을 통한 기능 확장
- 객체 합성과 위임은 행동 조합을 위한 상속보다 훨씬 유연
- 기존 객체들을 새로운 방식으로 조합
- 새로운 서브클래스를 정의하지 않고도 응용프로그램에 새로운 기능성을 추가
- 객체 합성을 많이 사용한 시스템은 이해하기가 어려움
- 많은 디자인 패턴에서는 그냥 서브클래스를 정의
- 다른 인스턴스와 새로 정의한 클래스의 인스턴스를 합성해서 기능을 재정의
(디자인 패턴 : Bridge, Chain of responsibility, Decorator, Observer, Strategy)
- 클래스 변경이 편하지 못한 점
- 소스 코드가 필요한데 없다고 가정
- 또 어떤 변경을 하면 기존 서브클래스의 다수를 수정
- 디자인 패턴은 이런 환경에서 클래스를 수정하는 방법을 제시
(디자인 패턴 : Adapter, Decorator, Visitor)
2. 디자인 패턴을 고르는 방법
- 패턴이 어떻게 문제를 해결
- 패턴의 의도
- 패턴들 간의 관련성
- 비슷한 목적의 패턴
- 재설계의 원인
- 설계에서 가변성