GoF 의 디자인 패턴 그 첫번째 Creational Pattern 생성 패턴입니다.
Creational Pattern 관련 자료들 - 개요, 장단점, 확장성/재활용성 측면, 타 패턴과의 관계
-Abstract Factory
the Abstract Factory Pattern provides a way to encapsulate a group of individual factories.
다양한 구성 요소 별로 '객체의 집합'을 생성해야 할 때 유용하다. 이 패턴을 사용하여 상황에 알맞은 객체를 생성할 수 있다.
Abstract Factory Pattern은 상태에 따라 어떤 객체를 생성하여 반환할 지에 포커스가 맞춰진 패턴
Abstract Factory는 여러종류의 관련 객체들을 묶어서 생성할 숭 ㅣㅆ는 클래스 구현에 중점을 둔 패턴이다.
장점 : 한번 구현해둔 Factory간 교체가 쉬워 간단하게 Product군을 변경하여 갖을수 있다.
단점 : 팩토리에서 Product를 종류별로 일일이 생성해줘야 하는 단점 인터페이스 확장이 어렵다();
if(isWindows()){
WinButton btn = new WinButton();
WinScroll scr = . . . .
WinCheck chk = . . .
.
.
.
}else if(isOSX()){
MacButton btn = . . . . .
.
.
.
}else if(isLinux()){
.
.
.
}
이런 단점을 해결하고자 ~ *
Abstract Factory 패턴이 대두됏다.
Abstract Factory Pattern
구체적 클래스를 정의하지 않고도 서로 관련성이 있거나
독립적인 여러 객체의 군을 생성하기 위한 인터페이스 제공
정의: 추상적인 부품을 조립해서 추상적인 제품을 만드는 추상적인 공장 같은 패턴
: 클라이언트에서 구상 클래스를 지정하지 않으면서도 일군의 객체를 생성할 수 있도록 하는 패턴
활용:
1. 생성되고 구성되고 표현되는 방식과 무관하게 시스템을 독립적으로 만들고자 할 때
2. 하나 이상의 제품군들 중 하나를 선택해서 시스템을 설정해야 하고 한번 구성한 제품을 다른 것으로 대체 가능할 때
3. 관련된 객체군을 함께 사용해서 시스템을 설계하고, 이 제품이 갖는 제약사항을 따라
야 할 때
4. 제품에 대한 클래스 라이브러리를 제공하고, 그들의 구현이 아닌 인터페이스를 표현하
고 싶을 때
결과:
1.구체적인 클래스를 분리한다 –
추성클래스가 정의한 인터페이스를 통해서만 클라이언트 프로그램을 작성한다
2. 제품군을 쉽게 대체할 수 있도록 한다
3. 제품간의 일관성을 증진한다
4. 새로운 종류의 제품을 제공하기 어렵다 –
새로운 제품에 대해 추상 팩토리를 확장하는 것이 어렵다
1. 이 패턴의 목적
서로 관련성 있더나 독립적인 여러 객체의 군을 생성하기 위한 팩토리를 따로 구현 및 추가가 가능도록.
2. 이 패턴의 장점
제품을 생성하는 실제 팩토리와 분리 시켜져서 서로 다른 상황별로 적당한 제품을 생산할 수 있는 다양한 팩토리를 자유롭게 확장 가능하다.
3. 이 패턴의 단점
인터페이스의 확장이 어렵다.
4. 이 패턴의 재사용성과 확장성에서의 측면
팩토리의 확장과 교환이 쉽다
재활용적인 측면은 떨어진다 새로운 Product군의 추가에 대한 요구 사항이 생기면,
AbstractFactory를 수정하고 그 녀석을 상속하는 모든 CocreteFactory에 대한 수정이
필요하므로 확장성이 떨어진다고 볼수 있다.
abstractFactory는 내부적으로 factoryMethod의 모습을 가지고 있다.
하지만 abstractFactory는 구성의 측면에서 객체를 생성하고 있고
factoryMethod는 상속의 측면에서 객체를 생성하고 있다.
AbstractFactory 클래스는 팩토리 메서드 패턴을 이용하여 구현된다.
========================================================================================================================================
-Builder
생성하는 방법과 표현하는 방법을 분리. 분리의 이유는 생성하는 방법이 복잡하기 때문임.
복잡한 인스턴스를 조립한다.
(생성)과정은 변하지 않는다.
공정, 부품(operation)만 변한다. -> 다른 표현을 만들 수 있게 한다.
Builder Pattern은 제품 생성 단계(절차, 방법)에 따라 생성된 객체들을 어떻게 조립하여 어떤 완성품(Product)을 생성하여 반환할 지에 포커스가 맞춰진 패턴
Abstract Factory와 Builder의 차이점
Builder는 객체의 단계별 생성에 중점을 준다. 생성한 제품을 반환.
Abstract Factory 패턴은 제품의 유사군을 생성해달라고 요청만 한다. 즉시 각 부품을 반환.
Builder Pattern
복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리해
서로 다른 표현이라도 이를 생성할 수 있는 동일한 구축 공정을 제공할 수 있다
정의: 구조를 가진 인스턴스를 쌓아 올리는 패턴 : 제품을 여러 단계로 나눠서 만들 수 있도록 제품 생산 단계를 캡슐화하고 싶을때 사용
활용:
1. 복합 객체의 생성 알고리즘이 이를 합성하는 요소 객체들이 무엇인지
이들의 조립방법에 독립적일 때 – RTF reader
2. 합성할 객체들의 표현이 서로 다르더라도 구축 공정이 이를 지원해야 할 때
결과:
1. 제품에 대한 내부 표현을 다양하게 변화할 수 있다
2. 생성과 표현에 필요한 코드를 분리한다
3. 복합객체를 생성하는 공정을 더 세밀히 나눌 수 있다 –
director의 buildPart()를 통해
관련 패턴: Abstract Factory 패턴이 복잡한 객체를 생성해야 하는 경우 Builder 패턴과 비슷한데, Builder는 복잡한 객체의 단계별 생성에 중점을 두고, Abstract Factory는 제품의
유사군들이 존재하는 경우 유연한 설계에 중점을 둔다.
Builder 패턴은 생성의 마지막 단계에서 생성한 제품을 반환하고 Abstract Factory 패턴에서는 만드는 즉시 제품을 반환한다. 이는 Abstract Factory 패턴에서 만드는 제품은 꼭
모여야만 의미있는 것이 아니라 하나만으로도 의미가 있기 때문이다
Builder패턴의 유용성
복잡한 객체를 생성하는 데 있어 그 객체를 구성하는 부분 부분을 생성한 후 그것을 조합해도 객체의 생성이 가능할 때
서로 다른 표현 방식을 가지는 객체를 동일한 방식으로 생성하고 싶을 때
Builder 패턴의 장단점
객체의 내부 구조를 변경시킬 필요가 있을 경우 기존 소스코드에는 영향을 주지 않고, 새로운 하위 클래스를 추가 정의 할 수 있다.
Builder와 Director 클래스는 서로 독립적으로 수정되거나 재사용될 수 있다.
객체 생성 과정을 좀더 세밀하게 제어할 수 있다.
새로운 종류의 객체 생성을 추가하기는 쉬우나, 객체를 구성하는 각 부분들을 새롭게 추가하기는 어렵다.
구현 관련 사항
설계시 모든 하위 클래스들이 동일한 인터페이스를 가질 수 있도록 만든다.
Builder 패턴에 의해 생성되는 객체들은 서로 어떤 관계도 가질 필요가 없다
⇒ 하위 클래스를 정의하는 이유가 서로 다른 종류의 객체를 생성하기 위함.
최상의 클래스가 반드시 Abstract Base Class로 정의될 필요가 없다.
예) Translator 클래스에서 각 멤버 함수에 대해 기본적인 구현을 해준다면,
그 하위 클래스들이 멤버함수를 구현할 필요성이 줄어든다.
1. 이 패턴의 목적
복합 객체의 생성 과정과 표현 방법을 분리함으로써 동일한 생성 공정이 서로 다른 표현을 만들 수 있게 한다.
복잡한 객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리하여 서로 다른 표현이더라도 이를 생성할 수 있는 동일한 절차를 제공할수 있도록
(특정 instance들을 생성할 때 수행되어야 할 작업이 동일할 경우 적용될 수 있는 pattern)
2. 이 패턴의 장점
객체 내부 표현을 다양하게 변화시킬수 있따 (builder만 교체하면..)
(생 성될 때(초기화 될 때) 동일한 과정을 수행해야 하는 서로 다른 Class의 instance에 대하여 통일된 생성방법(초기화 방법)을 제공할 수 있다는 것이다. (서로 동일한 상속관계를 가지지 않는 instance를 동일한 방법으로 생성할 수 있다!!!))
객체의 부분 부분을 생성하는 것과 그들을 조합해서 전체 객체를 생성하는 것이 서로 독립적으로 이루어질수 있다
서로 다른 펴현 방식을 가지는 객체를 동일한 방식으로 생성이 가능다.
3. 이 패턴의 단점
새로운 종류의 객체 생성을 추가하기는 쉬우나 객체를 구성하는 각 부분들을 새롭게 추가하는 것은 어렵다 ( AbstractBuilder의 인터페이스를 수정해야 하는 불상사가 생긴다.)
4. 이 패턴의 재사용성과 확장성에서의 측면
Build하는 부분이 캡슐화되서 (복잡한 생성 과정이..) 새로운 product가 추가되어도 쉽게 abstractBuilder를 상속하여 재사용성과 확장성이 좋다 build측면에서는 말이다.
하지만 build과정에 대한 추가적인 요구 사항이 생겻을 경우 abstractBuilder를 수정하고 그 녀석을 상속하는 모든 녀석을 수정해야할수도 있으므로 이런 측면에서의 확장성은 좀 떨어진다 볼수 있다.
5. 다른 생성 패턴과의 연관성
Builder 패턴도 AbstractFactory와 FactoryMethod와 비슷한 모습을 가지고 있다.(자기 자신 ConcreteBuilder와 관련있는 Product를 생성하여 공통된 모습대로 build하니깐..abstractFactory와 비슷하고 생성하는 부분을 서브 클래스가 전담하니깐 factoryMethod의 모습도 가지고 있다 볼수 있다.) 하지만,
>> Factory Method는 어떤 객체를 생설할 때 여러 단계가 아닌 한단계로 서브 클래스에서 생성만 맡는다 이런점이 builder와 다른점 builder는 객체를 getResult하기 전까지 이래 저래 조합을 하고 return하는데 factoryMethod는 그렇지 않다.
위키피디아 : abstractFactory와 builder의 차이는 abstractFacatory는 생성 요청에 대해서 즉시 반환을 하는 반면에 Builder는 step by step으로 반환을 한다고 정의하고 있다
AbstractFactory와 Builder패턴은 비슷한 모습을 보인다.
하지만 빌터 패턴은 복잡한 객체의 단계별 생성에 중점을 둔 반면,
추상 팩토리 패턴은 제품의 유사군들이 존재할 때 유연한 설계를 하기 위하는데 중점을 둔다.
빌더 패턴은 생성의 마지막 단계에서 생성한 제품을 반환한다.
하지만 추상 팩토리 패턴은 만드는 즉시 반환한다.
========================================================================================================================================
- Factory Method
팩토리 메소드 패턴은 객체를 생성하기 위한 인터페이스를 정의한다.
어떤 클래스의 인스턴스를 만들지는 서브 클래스에서 결정하게 되는것이다.
객체 생성을 처리하는 클래스를 캡슐화 시켜 놓으면 구현을 변경할때 여기저기 다 들어가서 고칠 필요없이 이 팩토리 메소드만 고치면 되기 때문에 . . .
단점 : Concrete Creator 의 종류가 많아지면 애플리케이션의 코드 수정이 불가피하다는 것
Factory Method Pattern은 통일된 방법으로 객체를 만들고, 통일된 방법으로 생성된 객체를 조작하면서도, 각 생성된 객체들은 종류에 따라 자신만의 구현으로 동작할 수 있게 해주는 구조이다
단점 : Factoty Method Pattern은 생성할 객체의 종류가 많아 질수록 그만큼의 하위 클래스를 정의해야 한다는 것이 부담이 될 수 있다
1. 이 패턴의 목적
객체를 생성하고 동작하는 인터페이스를 정의하는데, 객체를 생성하는 역할은 서브 클래스에게 위임하는 패턴
팩토리 메소드 패턴을 이용하면 클래스의 인스턴스를 만드는 일을 서브클래스에게 맡기는것이다.
생산자 클래스 자체가 실제 생성될 인터페이스를 전혀 고려하지 않고 정의될수 있다.
2. 이 패턴의 장점
객체를 인스턴싱 하는 부분과 객체를 사용하는 부분을 분리하였으므로,
나중에 아무리 새로운 Product가 생기더라도 Creator의 수정 없이 확장이 가능하다.
어떤 객체를 생성할 것인지와는 무관하게 동일한 형태로 Creator의 프로그래밍이 가능하다는 점이다.
3. 이 패턴의 단점
생성할 객체의 종류가 달라질 때 마다 새로운 서브 클래스를 정의해야 하기 때문에 프로덕트의 수대로 불필요하게 많은 서브 클래스가 정의되야 한다는 단점이 있다.
4. 이 패턴의 재사용성과 확장성에서의 측면
서브클래스가 확장을 통하여 같은 타입의 어떠한 Product든지 인스턴싱하도록 정의가 가능하다.
동일 타입의 프로덕트를 생성하는 한 무한으로 서브 클래스의 확장이 가능하다.
Product가 아무리 생겨도 Creator의 변경 없이 이용이 가능하므로 재사용성 측면에서 보더라도 매우 큰 장점이 있다.
직접 생성자를 호출해서 객체를 생성하는 것보다 훨씬 유연하고 확장성이 있는 구조다
5. 다른 생성 패턴과의 연관성
========================================================================================================================================
이 세가지 패턴의 공통점은 객체를 실제로 생성하는 부분과 사용하는 부분을 따로 둠으로써
객체를 실제로 사용하는 Client 들이 쉽게 복잡한 객체를 사용 할 수 있게 해준다.
========================================================================================================================================
- Prototype
(Abstract Factory와 경쟁관계인 패턴이다 왜일까도 알아보자.)
Abstract Factory 나 Builder 패턴 등과는 달리 객체를 생성해주기 위해 별도의 클래스를 정의할 필요가 없다.
Prototype 패턴은 실행 시간(Run-Timr)에도 생성할 객체의 종류를 추가 또는 삭제할 수 있다.
(단) Clone( ) 멤버 함수를 구현해야 한다.
복사해서 인스턴스를 만든다.
※ 생성되는 과정이 복잡할 때 사용한다
견본 인스턴스를 사용하며 그걸 복제하여 새로운 객체를 생성한다.
제품의 생성, 합성, 표현 방법에 독립적인 제품을 만들때.
관련 패턴
Abstract Factory : prototype과는 경쟁적인 관계.
1. 이 패턴의 목적
복잡한 객체를 인스턴싱하기 위한 목적에서 발생한 패턴이다.
어던 클래스의 인스턴스를 만드는 것이 자원과 시간을 많이 잡아 먹거나 복잡한 경우에 프로토타입 패턴이 적당하다.
2. 이 패턴의 장점
클라이언트는 새로운 인스턴스를 만드는 복잡한 과정을 몰라도 된다.
클라이언트에서는 구체적인 형식을 모르는 아무리 복잡한 객체 더라도 쉽게 객체를 생설할 수 있다.
상황에 따라서 객체를 새로 생성하는 것 보다 객체를 복사하는 것이 더 효율적일 수 있다.
3. 이 패턴의 단점
shallow Copy 단순카피 피상적카피: 레퍼턴스만 카피 하는 것 자바에서 clone()는 shallow Copy이다
Deep Copy 깊은 카피 : 실제 값 까지 복사 하는 것
4. 이 패턴의 재사용성과 확장성에서의 측면
5. 다른 생성 패턴과의 연관성
========================================================================================================================================
- Singleton
클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할 수 있는 방법을 제공.
클래스에서 만들 수 있는 인스턴스가 오직 하나(혹은 원하는 만큼만)일 경우 이에 대한 접근을 어디에서든지 하나로만 통일하여 제공한다.
========================================================================================================================================
RECENT COMMENT