1.
Facade Pattern
·
새로운 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 나잎인것 처럼 사용할 수 있게 된다.
·
결과 : 이미 존재하는 객체들이 그들의 인터페이스에 의해 제한받지 않고 새로운 클래스 구조에 맞출수 있게 된다.
·
구현 : 또 다른 클래스에 기존에 존재하고 있던 클래스를 포함시킨다. 포함하는 클래스는 요구되는 인터페이스에 조화시키고 포함되는 클래스의 메소드를 호출한다.
3.
Bridge Pattern
·
Bridge 패턴에 통합된 Adapter 패턴을 보게 되는 것일 일반적
·
합성
디자인
패턴으로
구현되는
경우가
많다.
Bridge 패턴의 핵심 특징
·
의도 : 구현을
이용하는
객체의
집합으로부터
구현의
집합을
분리한다.
·
문제점 : 추상클래스의
파생
클래스가
폭발적으로
증가되는
것을
막는다.
·
해결법 : 이용하고자
하는
모든
구현에
대한
인터페이스를
정의하고, 이
구현을
이용하는
추상
클래스의
파생
클래스를
갖는다.
·
참
여자와
협력자
: 구현되고
있는
객체에
대해
인터페이스를
정의한다. Implementor는
특정한
구현
클래스에
대해
인터페이스를
정의한다. Abstraction으로부터
파생
클래스는
어떤
특정한
ConcreteImplementor가
이용되는지
알지
못하면서 Implementor로부터
파생
클래스를
이용한다.
·
결과 : 구현을
이용하는
객체로부터
그
구현을
분리하는
것은
확장성을
높여준다. 클라이언트
객체는
구현에
대한
사항을
알지
못한다.
·
구현
o
추상
클래스에
구현을
캡슐화
한다.
o
구현되고 있는 추상화 개념의 기본 클래스 안에 구현에 대한 처리를 포함한다.
4.
Abstract Factory
·
시스템이
항상
자기의
상황을
위해
정확한
객체를
얻도록
보증한다.
Abstract Factory 패턴 : 핵심 특징
·
의도 : 특정
클라이언트를
위한
객체
집합이나
군을
갖기를
원한다.
·
문제점 : 관련된
객체
군은
인스턴스화
되어야
한다.
·
참여자와
협력자
: AbstractFactory는
요구되는
객체
군의
각
맴버를
생성하는
방법을
위한
인터페이스를
정의한다. 일반적으로, 각각의
군은
자신의
유일한
ConcreteFactory를
가짐으로
객체로
생성된다.
·
결과 : 이
패턴은
객체를
이용하는
방법에
대한
로직으로부터
어떤
객체를
이용할것인가
하는
규칙을
분리한다.
·
구현 : 어떤
객체가
만들어지는지를
명시한
추상
Class를
정의하자. 그런
다음
객체들의
각
군을
위해
하나의
구체적인
클래스를
구현하자.
5.
Stratege Pattern
·
GOF에서 제시한 원칙에 의해서 만들어진다.
·
새로운
요구사항을
처리하는
방법으로
사용
o
객체의
재사용을
위해
상속을
최대한
피해서
사용하자.
o
상속이
아닌,
소유로서
구현한다. : 변화하는 개념을 캡슐화 한다.
Strategy 패턴 : 핵심 특징
·
의도 : 서로다른
비지니스
규칙
또는
알고리즘을
만들어
이들이
발생하는
전후
관계에
맞게
이용할
수
있게
해준다.
·
문제점 : 알고리즘의
선택은
클라이언트의
요청에
맞게
데이터의
행동에
맞게
적용되어야지
된다.
단순히
변경되지
않는
규칙만을
가지고
있다면
Strategy 패턴은
필요가
없다.
·
해결법 : 알고리즘의
구현과
선택을
분리하자. 전후
관계를
기반으로
선택을
하도록
하자
·
참여자와
협력자
o
Strategy는 다른 알고리즘이
어떻게
이용되는지
명시한다.
o
ConcreteStrategie들은 이런 다른 알고리즘을 구현한다.
o
Context는 Strategy 타잎의 레퍼런스로 구체적인 ConcreteStrategy를 이용한다.
·
결과
o
Strategy 패턴은 알고리즘의 한 군을 형성한다.
o
switch 문 if/else 조건문이 제거된다.
o
모든 알고리즘이 동일한 방법으로 호출되어야지 된다.
·
구현
o
알고리즘을
호출하는
방법을
명시하는
추상
메소드를
갖는
추상클래스를
포함하는
클래스를
갖는다.
: SerialPolling
o
각각의
파생
클래스는
필요에
따라
알고리즘을
구현한다. : StrignParser