생성패턴(creational pattern) :: 디자인 패턴

Abstract Factory



Abstract Factory 패턴의 구조는 위 그림과 같다. AbstractFactory라는 추상 클래스가 있고, 그 추상 클래스는 필요한 객체들을 생성하는 인터페이스를 가지고 있다. 실제로 객체를 생성하는 역할을 맞는 클래스(ConcreteFactory)들은 AbstractFactory 추상클래스를 상속하고 객체 생성 인터페이스를 구현한다. AbstractFactory 추상 클래스를 상속하는 ConcreteFactory를 여러 종류 만들 수도 있는데 각 클래스가 하나의 객체 Family를 이루게 된다. Client는 ConcreteFactory가 생성하는 실제 객체들(Product..)들의 부모인 AbstractProduct에 대해서만 알고 있어도 된다.
Abstract Factory 패턴은 ConcreteFactory만 교체하면 전체 Product들이 바뀌는 효과를 낼 수 있다. 흠..내 생각에 이런 것이 필요한 대표적인 경우로는 인터페이스의 스킨기능을 들 수 있을 것 같다. 책에도 이 패턴이 대표적으로 사용되는 경우가 인터페이스의 구성요소를 통째로 갈아끼우는 식의 구현이 필요할 때라고 적혀 있다.

Builder


Builder 패턴의 구조는 위 그림과 같다. Director가 Builder에게 어떤 객체의 생성을 요청하면 Builder가 척척 만들어서 Director에게 제공한다. 객체 생성을 전담하는 클래스가 따로 있다는 점에서 Abstract Factory패턴과 비슷하긴 한데, 약간 다른 점은 주로 Builder패턴은 복잡한 객체를 순서대로(step by step)만드는 반면 Abstract Factory 패턴은 주로 한 종류로 구분할 수 있는(Family) 객체들을 만드는 것에 중점을 두고 있다.

Factory Method


Factory Method패턴은 가장 간단한 생성 패턴이라고 한다. 별거 없이 객체를 직접 new로 생성하지 않고 FactoryMethod를 통해서 생성하는 방법이다. 흠..나름대로 Creator를 여러가지로 상속해서 확장을 꾀할 수 있다.

Prototype



가장 이해하기 힘들었던 패턴이다. 아직도 언제 어떻게 사용해야 할지 잘 모르겠다. C++관점으로 설명하자면. Client는 Prototype 추상 클래스의 포인터를 가지고 있다. Client가 생성될 때 적당한 ConcretePrototype(Prototype추상 클래스를 상속한 구체 클래스)를 생성하여 Client가 가지고 있는 Prototype포인터에 대입해서 유지 한다. Client가 객체를 생성하고 싶을 때 Prototype포인터에 Clone함수를 호출해서 생성한다.
Prototype 패턴의 핵심은 바로 Clone인터페이스 이다!

Singleton
Singleton패턴은 전체 프로세스 상에서 객체가 유일하게 생성되는 클래스를 정의하는 패턴이다. 이 이야기는 More Effective C++에 이미 나왔던 이야기인데, 클래스의 생성자를 public으로 하지 않으면 직접 클래스의 객체를 생성할 수 없게 된다는 점을 이용하면 된다.
클래스의 생성자를 protected나 private으로 하고, 클래스의 객체를 생성하는 인터페이스를 따로 만든다.
간단한 소스로 이해 해보자.

  1. class Singleton {
  2.   public:static void Singleton* Instance();
  3.   protected:static Singleton();
  4.   private:static Singleton* _instance;
  5. };
  6.  
  7. Singleton* Singleton::_instance = 0;
  8.  
  9. Singleton* Singleton::Instance(){
  10.   if(_instance == 0){
  11.     _instance = new Singleton;
  12.   }
  13.   return _instance;
  14. }



2007/06/22 14:44 2007/06/22 14:44
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

디자인 패턴 for 자바 :: Design Pattern for JAVA

2005년도 한창 패턴에 관심을 갖던 시기에 구한 도표인데.. 출처는 기억이 나질 않는군요..

디자인패턴 Design Pattern

2007/06/21 17:50 2007/06/21 17:50
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

구조패턴(structual pattern) :: 디자인 패턴

구조 패턴이라고 해석할 수 있을까나? structural pattern들은 객체들을 잘 구슬려서 어떤 구조를 만들어 내는 패턴들이다. 분류가 왜 이렇게 된 건지 잘 이해가 되진 않는다. 여하튼 패턴들을 살펴보자.

Adapter

Adapter패턴은 인터페이스가 서로 맞지 않는 두 클래스 사이에서 인터페이스를 맞춰주는 역할을 한다. Adaptee라는 클래스가 이미 존재한다고 하자.(어디 존재하는지는 별로 중요하지 않고..라이브러리 안쪽에 있을수도.. 소스코드로 있을수도..) Target에서 뭔가 작업을 하려고 하는데 그 작업이 이미 Adaptee에 구현된 작업과 매우 유사하다. 그런데 Target과 Adaptee의 인터페이스 구조가 달라서 어떻게 하기가 좀 곤란하다. 그럴 때 Adapter패턴을 사용한다. Adapter는 Target을 public상속(interface 상속)하고, Adaptee는 private상속을 해서(implementation만 상속한다는 뜻) Adapter에서는 Target의 인터페이스를 Adaptee의 구현을 이용해 구현하면 된다.(위쪽 그림 – Class Adapter)
private상속을 이용하지 않고 Adapter가 Adaptee를 멤버로 가지고 직접 Adaptee객체를 이용해 Adaptee의 구현을 활용할 수도 있따.(아래 그림 – Object Adapter)

실제 예를 들어 설명하면, Shape라는 추상 클래스가 있다. 어떤 모양을 나타내는 것일 테다. 이놈을 상속해서 LineShape도 만들 수 있고, CircleShape도 만들 수 있을 거다. TextShape도.. 그런데 TextShape를 만들려고 하다 보니 이미 TextView라는 이름으로 구현하려고 했던 대부분의 기능이 구현되어 있는 클래스가 있다고 해보자. TextShape를 TextView의 구현을 이용해서 만들고 싶다. 이럴 때 Adapter패턴을 적용하면 딱 이다. TextShape를 Shape를 public상속, TextView를 private상속하게 하거나, TextShape가 TextView의 객체를 가지고 구현을 이용하게 하거나 하면 될 것이다.


Bridge

이 패턴을 클래스의 추상부분과 구현을 분리 시켜서 뭔가를 얻어 보려는 패턴이다. 이게 여러모로 쉽게 확장을 할 수 있게 해준다. 역시 예를 들어 알아보자. 책에 나와 있는 Window시스템을 보자.
그냥 생각해서 Window를 나타내는 추상 클래스가 있고, 이놈을 상속해서 XWindow시스템, PMWindow시스템 이렇게 늘려간다고 해보자. 이제 아이콘을 나타내기 위해 IconWindow라는 놈을 만들려고 하면, XWindow용으로 XIconWindow도 만들어야 하고, PMWindow용으로 PMIconWindow도 만들어야 한다. 계속 추가 시켜나가야 할 양이 많아진다. 즉 확장이 쉽지 않다.
이런 놈을 Bridge패턴을 적용해서 이렇게 만들면 어떨까? Window라는 추상 클래스를 만든다. 그리고 WindowImp라는 구현을 담당하는 추상 클래스를 만든다. Window를 상속하여 IconWindow, TransientWindow등을 만든다. 이때 이 클래스들의 인터페이스는 WindowImp를 상속한 클래스들의 구현을 이용해서 구현한다. WindowImp를 상속하여 XWindowImp, PMWindowImp를 만들 수 있을 거고, Window를 상속하는 놈들은 이렇게 구현된 것들을 이용해서 만드는 것이다. 흠.. 이때 XWindowImp와 PMWindowImp는 Window를 상속하는 클래스들에서 필요할 만한 기본적인 구현들을 포함하고 있어야 한다.


Composite

Composite패턴은 쉽게 말해 묶음을 지을 수 있게 하고, 묶음을 낱개하고 똑같이 취급할 수 있게 하는 패턴이다.
흠..위 그림을 보면 Component 추상 클래스가 있다. 이것을 상속해서 Leaf클래스를 만들 수도 있고, Composite클래스를 만들 수도 있다. Composite클래스는 Component들을 Child로 포함할 수 있다. Composite도 Compnent니까 Composite가 Composite를 recursive하게 포함할 수 있다는 소리다. 이런 패턴을 주변에서 많이 볼 수 있다. 흠..컴퓨터 시스템만 해도 그렇다. 몇 개의 부품을 모으면 하나의 모듈이 되고 그 모듈이 또 전체 컴퓨터 시스템에 참가 하고.. 어쩌고 저쩌고.. 궁시렁 궁시렁..


Decorator

Decorator는 이름에 걸맞게 장식을 하는 패턴이다.
후훗. 그러니까.. Decorator는 Component를 상속하고 Component하나를 자기 안에 가지고 있는다. 그리고 Operation을 할 때 그 가지고 있던 Component의 Operation을 수행한다. 이때, Decorator는 그 Operation외에 어떤 작업(AddedBehavior)를 추가적으로 수행한다. 기본 작업(Component의 Operation)에 어떤 작업(AddedBehavior)를 추가 해서 장식을 하는 것이다. 실례를 들어 보자.
어떤 인터페이스 시스템에 VisualComponent라는 추상클래스가 있다. 그 추상 클래스를 상속하여 여러 인터페이스 요소들을 만드는데 TextView라는 것이 있다고 하자. 이 TextView를 포함한 VisualComponent들에 ScrollBar나 Border를 추가하고 싶다고 할 때, Decorator패턴을 사용할 수 있다.

위 그림을 보라!


Facade

Facade패턴은 조금 단순하다. 아래 그림을 보라.

이렇게 subsystem들을 외부에 공개하는 객체를 만드는 패턴을 Facade패턴이라고 한다.


Flyweight

이 패턴은 아주 자주 사용되는 객체들을 공유해서 과도한 메모리 사용량을 줄일 수 있는 패턴이다.(과도하다기 보다는 거의 구현 불가능한 정도의 메모리 사용량을 필요로 하는 경우라고 할 수도 있겠다.) 대표적인 예로, 문서 편집기를 만들 때, 각 글자 객체들을 관리하는 예가 책에 제시되어 있다. 아래 다이어그램을 보자.

GlyphFactory는 _character에 Character클래스의 객체들을 쭉 가지고 있는다. Character의 종류라고 해봤자 얼마 안될 것이기 때문에 쭉 가지고 있으면서 공유해서 사용하면 된다. 위의 경우 글자의 폰트등은 GlyphContext에서 관리해서 꾸며준다. 흠..자세히 이해하긴 힘들어서 더 이상 설명은 곤란..ㅠ.ㅠ

Proxy

Proxy패턴은 어떤 객체를 대신하는 Proxy객체를 만드는 패턴. 네트워크 저편에 있는 어떤 객체를 대신하는 remote proxy, 객체가 너무 커서 꼭 필요할 때만 생성해서 사용하게 큰 객체를 대신하는 virtual proxy, 원래 객체를 숨겨서 권한에 따라 접근 성을 다르게 주게 할 수 있는 protection proxy, 스마트 포인터등의 smart reference등으로 사용할 수 있는 패턴이다.
2007/06/21 17:44 2007/06/21 17:44
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다