·         새로운 Class나 인터페이스의 정립

·         복잡한 시스템을 쉽게 사용한다.

·         시스템의 한 부분만을 이용하거나 특별한 방법으로 시스템을 이용하도록 한다.

·         보다 더 단순하고, 사용하기 쉬운 시스템 또는 요구에 맞는 최적화된 시스템을 갖게 된다.

Facade 패턴 : 핵심 특징

의도 : 기존에 존재하고 있던 시스템을 이용하는 방법을 단순화 하고 싶다. -> 자신만의 인터페이스를 정의한다.

·         문제점 : 복잡한 시스템의 오직 부분만을 이용해야지 된다. 또는 특별한 방법으로 시스템과 상호작용 되어야 한다.

·         해결책 : 기존에 존재하고 있던 시스템을 이용하려고 하는 Client를 위한 새로운 인터페이스를 제시한다.

o    새로운 Class에서는 기존의 Class를 소유(has - a)하게 된다.

o    새롭게 외부로 노출된 방법을 통해서, 기능을 구현하게 된다.

·         참여자와 협력자 : Client가 좀더 사용하기 쉽도록 특별한 인터페이스를 제시한다.

·         결과

o    필요한 Sub System의 이용을 단순화 한다. : 부분만을 이용하고, 특별한 방법으로의 시스템과 상호작용되기 때문

o    모든 기능을 다 처리하지는 않는다.

·         구현

o    필요한 인터페이스를 갖는 새로운 Class를 정의한다.

o    새롭게 만들어진 Class에서 기존에 존재하던 시스템을 이용하게 된다.

·         새로운 인터페이스를 만들자.

o    올바른 작업을 수행하지만, 잘못된 인터페이스를 가진 객체를 위해 새로운 인터페이스를 생성하기 위한 방법이 필요하다.

·         Client 객체가 상세한 사항을 알 필요가 없게 하자.

 Adapter 패턴 : 핵심 특징

·         의도 : 통제 범위 이면에 있는 기존에 존재하고 있던 객체를 특별한 인터페이스와 조화시키자.

·         문제점 : 시스템은 올바른 데이터와 행위를 가지고 있지만, 잘못된 인터페이스를 가지고 있다. 일반적으로 정의하고 있거나 이미 정의된 추상 클래스의 파생 클래스를 만들기 위해 사용된다.

·         해결법 : Adapter 패턴은 원하는 인터페이스를 가진 래퍼를 제공한다.

·         참 여자와 협력자 : Adapter는 자신의 Target 클래스(Adapter 클래스는 이 Target 클래스로부터 파생)가 가진 인터페이스와 조화시키기 위해 Adaptee 클래스의 인터페이스를 적응시킨다. 이는 Client가 Adaptee를 마치 Target 나잎인것 처럼 사용할 수 있게 된다.

·         결과 : 이미 존재하는 객체들이 그들의 인터페이스에 의해 제한받지 않고 새로운 클래스 구조에 맞출수 있게 된다.

·         구현 : 또 다른 클래스에 기존에 존재하고 있던 클래스를 포함시킨다. 포함하는 클래스는 요구되는 인터페이스에 조화시키고 포함되는 클래스의 메소드를 호출한다.

·         Bridge 패턴에 통합된 Adapter 패턴을 보게 되는 것일 일반적

·         합성 디자인 패턴으로 구현되는 경우가 많다.

Bridge 패턴의 핵심 특징

·         의도 : 구현을 이용하는 객체의 집합으로부터 구현의 집합을 분리한다.

·         문제점 : 추상클래스의 파생 클래스가 폭발적으로 증가되는 것을 막는다.

·         해결법 : 이용하고자 하는 모든 구현에 대한 인터페이스를 정의하고, 이 구현을 이용하는 추상 클래스의 파생 클래스를 갖는다.

·         참 여자와 협력자 : 구현되고 있는 객체에 대해 인터페이스를 정의한다. Implementor는 특정한 구현 클래스에 대해 인터페이스를 정의한다. Abstraction으로부터 파생 클래스는 어떤 특정한 ConcreteImplementor가 이용되는지 알지 못하면서 Implementor로부터 파생 클래스를 이용한다.

·         결과 : 구현을 이용하는 객체로부터 그 구현을 분리하는 것은 확장성을 높여준다. 클라이언트 객체는 구현에 대한 사항을 알지 못한다.

·         구현

o    추상 클래스에 구현을 캡슐화 한다.

o    구현되고 있는 추상화 개념의 기본 클래스 안에 구현에 대한 처리를 포함한다.

·         시스템이 항상 자기의 상황을 위해 정확한 객체를 얻도록 보증한다.

Abstract Factory 패턴 : 핵심 특징

·         의도 : 특정 클라이언트를 위한 객체 집합이나 군을 갖기를 원한다.

·         문제점 : 관련된 객체 군은 인스턴스화 되어야 한다.

·         참여자와 협력자 : AbstractFactory는 요구되는 객체 군의 각 맴버를 생성하는 방법을 위한 인터페이스를 정의한다. 일반적으로, 각각의 군은 자신의 유일한 ConcreteFactory를 가짐으로 객체로 생성된다.

·         결과 : 이 패턴은 객체를 이용하는 방법에 대한 로직으로부터 어떤 객체를 이용할것인가 하는 규칙을 분리한다.

·         구현 : 어떤 객체가 만들어지는지를 명시한 추상 Class를 정의하자. 그런 다음 객체들의 각 군을 위해 하나의 구체적인 클래스를 구현하자.

·         GOF에서 제시한 원칙에 의해서 만들어진다.

·         새로운 요구사항을 처리하는 방법으로 사용

o    객체의 재사용을 위해 상속을 최대한 피해서 사용하자.

o    상속이 아닌, 소유로서 구현한다. : 변화하는 개념을 캡슐화 한다.

Strategy 패턴 : 핵심 특징

·         의도 : 서로다른 비지니스 규칙 또는 알고리즘을 만들어 이들이 발생하는 전후 관계에 맞게 이용할 수 있게 해준다.

·         문제점 : 알고리즘의 선택은 클라이언트의 요청에 맞게 데이터의 행동에 맞게 적용되어야지 된다. 단순히 변경되지 않는 규칙만을 가지고 있다면 Strategy 패턴은 필요가 없다.

·         해결법 : 알고리즘의 구현과 선택을 분리하자. 전후 관계를 기반으로 선택을 하도록 하자

·         참여자와 협력자

o    Strategy는 다른 알고리즘이 어떻게 이용되는지 명시한다.

o    ConcreteStrategie들은 이런 다른 알고리즘을 구현한다.

o    Context는 Strategy 타잎의 레퍼런스로 구체적인 ConcreteStrategy를 이용한다.

·         결과

o    Strategy 패턴은 알고리즘의 한 군을 형성한다.

o    switch 문 if/else 조건문이 제거된다.

o    모든 알고리즘이 동일한 방법으로 호출되어야지 된다.

·         구현

o    알고리즘을 호출하는 방법을 명시하는 추상 메소드를 갖는 추상클래스를 포함하는 클래스를 갖는다. : SerialPolling

o    각각의 파생 클래스는 필요에 따라 알고리즘을 구현한다. : StrignParser