디자인 패턴(4) - 복제 양 돌리(Dolly) ?

이승일
E-mail:gaialee@icu.ac.kr
한국정보통신대학원대학교
Homepage:http://www.icu.ac.kr/

뉴스레터 3호에서는 동적으로 타입을 바꾸는 것을 가능하게 해 주는 TypeObject 패턴[1]에 대해서 이야기를 했다.  영화 ‘Terminator 3’를 보면 자신의 모습을 마음대로 바꿀 수 있는 인조인간이 나온다. 자신의 모습을 마음대로 바꿀 수 있다는 점에서 이 영화의 인조인간이 TypeObject와 비슷하다고 이야기하면 너무 지나친 비약일까? ^(^ 

이 번호에는 TypeObject 패턴의 저자들이 관련 패턴으로 열거한 것들 중에서 Prototype 패턴[2]에 대해서 이야기를 해 보려고 한다.  TypeObject 패턴이 자신의 모습을 마음대로 바꿀 수 있는 것이라면, 이 번호에 이야기 하려는 Prototype 패턴은 또 다른 자신을 복제(clone)할 수 있는 패턴이다.

1.  사고의 틀을 깨자!!

객체를 만들기 위해서는 무엇이 필요한가? 그렇다. 이 번호에서도 또 객체 생성에 대한 이야기를 하려고 한다. 하지만 기존의 널리 알려져 있는 방법과는 근본적인 부분에서 차이를 가지고 있는 방법이다. 

객체지향 프로그래밍 언어로 현재 가장 대중적인 언어를 들라면, C++와 Java언어를 들 수 있을 것이다. 지난 호에서도 알아 보았지만, 이 두 언어에서는 객체를 생성하기 위해서는 클래스(Class)를 먼저 만들고 instantiation이라 불리는  과정을 통해서 해당 클래스 타입의 객체를 생성하게 된다. 

그럼 클래스라고 불리는 것이 없으면 객체지향 언어에서는 객체를 생성할 수 없다는 것인가? 그렇지 않다. 클래스가 없이도 얼마든지 객체를 만들 수 있는 방법이 있다. C++와 Java처럼 클래스를 기반으로 객체를 생성하는 프로그래밍 언어를 ‘클래스 기반 언어(class-based language)라고 하고 클래스가 없이 임의의 객체를 기반으로 또 다른 객체를 생성하는 언어를 ‘프로토타입 기반의 언어(prototype-based language)’라고 하여 구분하고 있다. 

2.  프로토타입 기반 언어

그럼 클래스 없이 객체를 어떻게 생성한다는 말인가? 그 이야기를 하기 전에 근본적으로 객체를 생성한다는 것이 무엇을 의미하는지 곰곰이 생각해 보자. 클래스를 가지고 객체를 생성할 때의 기억을 떠올리면서…. 

하나의 객체란 일반적으로 자신의 상태(state) 정보를 저장하기 위해서 필요로 하는 데이터 구조(data structure)와 자신의 상태 변경과 관련된 하나 이상의 operation을 가진다. 객체마다 가지고 있는 상태 정보 저장을 위한 데이터 구조와 operation 등이 서로 다를 수도 있고, 경우에 따라서는 같은 데이터 구조와 operation을 가지고 상태 정보에만 차이를 가지고 있는 객체들도 있을 것이다. 후자의 객체들을 같은 타입의 객체라고 부르자. 클래스 기반의 언어에서는 같은 타입의 객체들을 무한히 찍어 낼 수 있는 클래스라는 이름의 거푸집을 만들어서 객체를 생성하는 것으로 볼 수 있다. 즉, 우리는 C++와 Java 언어를 사용해서 프로그램을 만들 때 필요한 거푸집을 매번 만들고 있는 것이다. 여기서 주의 깊게 보아야 할 부분은 생성하려고 하는 객체의 타입에 대한 정보를 클래스가 가지고 있고, 따라서, 우리가 클래스를 만든다는 것은 해당 컴파일러에게 생성 하려는 객체의 정보를 주고 있는 과정으로 생각할 수 있을 것이다. 

그럼 이제 다시 클래스가 없는 상태로 돌아가서 이야기를 해 보자. 클래스가 없다는 것은 생성하려고 하는 객체의 타입에 대한 정보를 다른 어떤 것으로부터 해당 컴파일러에게 일러 주어야 한다는 것을 의미한다. 그렇지 않으면, 어떻게 컴파일러가 우리의 의도를 알아차리고 우리가 원하는 객체를 생성해 줄 수 있다는 말인가? 디자인 패턴의 첫 번째 글에서도 이야기 했지만, 공짜는 없다(There’s no magic!!). 

그럼 생성 객체의 타입 정보를 줄 수 있는 다른 방법으로는 어떤 것이 있을까? 쉽게 생각 할 수 있는 것은 이미 생성되어 있는 다른 객체를 프로토타입(prototype)으로 해서 그 객체의  타입 정보를 주는 방법을 생각해 볼 수 있다. 다시 말해서, 프로토타입 기반의 언어는 객체 생성을 위해서 클래스가 아닌 객체를 타입으로 해서 다른 객체를 생성하는 과정을 거친다. 그럼 구체적으로 어떻게 다른 객체를 프로토타입으로 해서 다른 객체를 생성하는가? 엄밀히 그 과정은 새로운 객체가 생성되기 보다는 생물의 세포가 분열할 때처럼 자신과 똑 같은 또는 일부 기능을 가지는 객체를 메모리에 복제하는 과정으로 볼 수 있고, 일반적으로는 이 과정을 표현하기 위해서 ‘clone’이라는 용어를 사용한다. 

클래스 없이 객체를 생성하는 것에 대해서 전체적으로는 어떤 과정을 거치는지 이해할 수 있었을 것이다. 그럼 이제 구체적으로 clone이라는 과정이 어떻게 구현될 수 있고 이 것이 어떻게 구체적인 하나의 패턴으로 나타날 수 있는지에 대해서 이야기를 해 보겠다.

3.  문 제

간단한 드로잉(drawing) 프로그램을 만든다고 가정해 보자. 이 프로그램의 요구사항 중에 반드시 구현되어야 할 것은 사용자가 마우스 클릭만으로 원, 사각형 등과 같은 그림을 그릴 수 있어야 한다는 것이라고 한다. 이런 요구사항을 만족시키기 위해서 원, 사각형 등과 같은 프로토타입의 그림이 그려져 있는 팔래트(palette)를 구성할 수 있을 것이다[그림 1].

그림 1. 드로잉 프로그램의 팔래트

그림 1과 같은 팔래트가 마련되면, 사용자는 자신이 그리려고 하는 도형의 표본이 되는 프로토타입을 팔래트 위에서 찾아 마우스 클릭만으로 쉽게 그림 그리기를 시작할 수 있을 것이다. 그럼 이런 팔래트를 구현하기 위해서는 어떻게 해야 할까?

팔래트 위에 놓여있는 ‘원’을 클릭해서 도화지(그림이 그려지는 부분을 도화지라고 이름 붙여 보았다.)위에 놓았다는 것은 무엇을 의미하는가? 이 것은 하나의 ‘원’ 객체가 생성되었다는 것을 의미한다. 그럼 이제 문제는 객체 생성 방법 중에서 가장 효율적인 방법을 찾아서 이 과정을 구현하는 일이 남았다. 

우리가 알고 있는 객체 생성 방법을 쭉 열거하면서, 가장 효율적으로 보이는 것을 선택해 보자. 먼저, 해당 클래스로부터 직접적으로 객체를 생성하는 방법은 어떨까? 이 방법은 이 전의 뉴스레터에서 이야기 했듯이 해당 타입에 대한 정보를 모두 가지고 있어야 하는 문제 때문에 이용하는 객체와의 의존성이 너무 크다. 이 예에서 적용해 본다면, 마우스가 클릭될 때의 이벤트 핸들러가 팔래트에 등록되어 있는 모든 객체의 클래스 타입에 대한 정보를 가지고 있어야 하기 때문에, 프로토타입 객체의 클래스에 대한 수정이 가해지면 이벤트 핸들러의 소스 코드에서도 수정이 가해져야 한다. 그럼, Abstract Factory 패턴[2]을 이용하면 어떨까? (2호에서 Factory Method에 대한 설명을 하고 Abstract Factory 패턴에 대한 공부는 독자의 몫에 맡겼었는데, 이 글을 읽고 있는 독자가 Abstract Factory 패턴에 대한 지식이 있는지 모르겠다. 에라 모르겠다. ^(^ ) 이 패턴을 이용하면 프로토타입 객체의 클래스와 이벤트 핸들러와의 사이에 객체 생성에 대한 의존성을 거의 제거할 수 있기 때문에 좋은 방법이 될 수 있을 것이다. 3호에서 이야기한 TypeObject 패턴은 어떨까? 런타임 시에 팔래트에 있는 객체가 도화지에 생성될 객체의 타입 역할을 한다는 점에서는 TypeObject 패턴의 저자들이 지적했듯이 비슷한 상황이다[1]. 그러나, 구현에는 아주 심각한 문제가 생긴다. 왜냐하면 그 구현이 아주 복잡해지기 때문이다. 따라서, 현재까지 우리가 이야기한 객체 생성에 대한 패턴 중에서는 Factory Method 의 확장형인 Abstract Factory 패턴이 가장 유력하다. 그러나, 우리가 처음에 이야기 한대로 클래스에 대한 정보 없이 객체를 생성할 수 있는 방법으로 이 문제를 해결하여 보고 Abstract Factory 패턴과 비교해 보라. 아마 흥미로울 것이다.

4.  객체 복제 ? 돌리를 향한 객체의 꿈

프로토타입 패턴이 사용되기 위한 전재 조건이 있다. 그 것은 프로토타입으로 사용되는 객체가 자신을 복제할 수 있어야 한다는 것이다. 따라서, 우선 객체의 복제문제에 대해서 알아보자. 

객체 복제가 뭐 어려운가? 하는 독자도 있을 것이다. 그러나, 그리 간단히 생각할 수 있는 문제는 아니다. 그 이유는 객체라는 것 자체가 자신의 상태 정보를 위한 여러 타입의 데이터 구조를 포함하고 있다는데 있다. 객체 복제는 두 가지 형태가 있다. ‘Shallow copy’와 ‘Deep copy’라고 불리는 것이다[3]. 

(가) shallow copy                     (나) deep copy

그림 2. 객체 복제 방법

그림 2에 나타난 것처럼 ‘나’라는 객체와 이 객체에서 주소에 대한 정보를 표현하기 위해서 reference 하고 있는 ‘주소’라는 객체가 있다고 하자. ‘나’라는 객체를 복제했을 경우에 shallow copy의 경우에는 ‘나’ 객체가 포함하고 있는 변수 ‘이름’, ‘결혼유무’, ‘주소’가 가지고 있는 데이터에 대한 부분만을 복사한다. 따라서, 그림 2의 (가)의 경우처럼 ‘나’ 객체의 변수 ‘주소’의 경우에는  ‘주소’ 객체에 대한 reference값만 복사하여 결과적으로는 같은 ‘주소’ 객체를 reference하고 있다. deep copy의 경우에는 ‘나’ 객체에 포함되어 있는 변수인 ‘이름’, ‘결혼유무’에 대한 복사는 물론이고, 이 객체가 reference하고 있는 모든 객체를 그대로 복사하고 해당 reference 값은 이에 따라 변경된 객체에 대한 참조자(pointer)로 변경된다. 따라서, 내부적으로는 그림 2의 (나)와 같은 결과를 가져오게 된다.

그러면 다시 우리의 예제로 돌아가서 보자. 우리가 사용할 프로토타입 객체들은 자신을 복제할 때 어떤 복제 기능을 부여해 주어야 할까? shallow copy로 아니면 deep copy로? 원과 사각형 정도를 그리는데 필요한 객체는 다른 객체의 reference를 가질 필요가 없을 것이다. 따라서, shallow copy 정도면 충분할 것이다. 

그림 3. 프로토타입 객체의 클래스 다이어그램

그림 3처럼 프로토타입 객체로 사용할 각 객체가 자신을 복제할 수 있도록 하는 clone()이라는 메소드를 만들어 넣어 준다. 프로토타입 객체를 사용할 다른 객체들과의 의존성을 낮추기 위해서 Shape라는 인터페이스를 만들어 준다. 소스 코드를 보면 다음과 같이 될 수 있을 것이다.

interface Shape { public Shape clone(); }

class Circle implements Shape {
    …
    private Point center_;
    private int radius;
    …
    public Circle(Circle c_, Point newP_) {
       …
       center_ = c_.position(newP_);
       radius = c_.radius;
       …
    }
    …
    public Shape clone(Point mouseP_) {
       return new Circle(this, mouseP_);
    }
    …
    public Point position(Point p_) { … }
    …
}

Rectangle의 경우도 Circle의 경우와 비슷한 소스 코드를 가질 것이다. 이제 우리가 사용할 객체에 복제 능력을 부여해 주었다. 이제 복제 능력을 가진 프로토타입 객체를 가지고 팔래트를 만들어 보자.

5.  Prototype 패턴

프로토타입 패턴의 근본은 앞에서 이야기한 clone이라는 과정을 통해서 해당 객체에 대한 정보가 거의 없이 객체를 생성할 수 있다는 데 있다. 어떻게 그럴 수 있는지 이야기해 보겠다.

프로토타입 패턴을 이용해서 프로토타입 객체를 생성하기 위한 클래스 다이어그램은 그림 4와 같은 구조가 될 수 있을 것이다. 그림 4의 클래스 다이어그램에서 ‘PrototypeBuilder 클래스는 프로토타입 객체를 생성하여 ‘Palette’ 객체에 등록시키는 일을 한다. 그리고, Palette 객체는 PrototypeBuilder가 생성하여 등록시킨 프로토타입 객체를 보관하고 있다가, 팔래트를 사용하는 다른 객체가 프로토타입 객체를 원할 경우에, 해당 객체의 클래스를 이용하여 해당 객체를 새롭게 생성하는 것이 아니라, 해당 객체를 cloning 한다. 즉, 자신의 복제 객체를 준다.

그림 4. 팔래트를 위한 클래스 다이어그램

PrototypeBuilder와 Palette 클래스는 다음과 같이 구현될 수 있을 것이다.

class PrototypeBuilder {
    …
    private Palette pt_ = new Palette();
    …
    public void createPrototype() {
        …
        pt_.addShape(“circle”, new Circle());
        pt_.addShape(“rectangle”, new Rectangle());
        …
    }
    …
}
 

class Palette {
    …
    private Hashtable shapePool_ = new Hashtable();
    …
    public void addShape(String key, Shape sp_) {
        …
        shapePool_.put (key, sp_);
        …
    }
    …
    public Shape getShape(String key) {
        …
        return ((Shape)shapePool_.get(key)).clone();
    }
    …
}
 

위의 소스에서 볼 수 있듯이 Palette 객체는 외부의 객체가(여기의 예에서는 마우스가 도화지 위에 클릭 되었을 때의 이벤트 핸들러가) 프로토타입 객체를 원했을 경우에 해당 객체의 클래스를 이용해서 새로운 객체를 생성하고 이를 리턴하고 있지 않다. 대신에 관리하고 있는 객체의 clone()이라는 메소드를 호출함으로써 해당 객체의 복사본을 리턴해 주고 있다. 여기서 우리가 눈 여겨 봐야 할 곳은 Palette 객체가 cloning을 통해서 복제를 하고 있는 객체에 대한 타입 정보에 대해서 아는 것이 전혀 없다는 것이다. 재미있지 않은가?

위에서 예로든 자바 소소에 대해서 몇 마디 할 이야기가 있다. 사실 자바 언어는 클래스 기반의 언어이지만 객체 cloning에 대한 것을 언어 차원에서 제공해 주고 있다. 자바 언어의 모든 객체는 Object 클래스를 상속하고 있으며, 이 속에는 clone()이라는 메소드가 포함되어 있다. 그러나, 이 메소드는 항상 사용될 수 있는 것이 아니라, Cloneable이라는 인터페이스를 implement하는 클래스의 객체만 cloning을 지원해 주고 있다. 이 때의 cloning은 shallow copy가 된다. 위의 소스를 자바의 clone() 메소드를 이용해서 구현 예를 보이면, 어느 정도 그 내막을 알기 어렵다는 판단에서 일부러 shallow copy를 구현해 본 것이다. 

이제 이야기를 정리해 보자. 그림 5는 GoF 책에 있는 Prototype 패턴을 필자가 UML 버전으로 바꾼 것이다. 

그림 5. Prototype 패턴

이 패턴에서 client 클래스는 prototype 객체를 이용한다는 의미에서 client라는 이름이 붙여졌다. 따라서, client를 구현할 때 많이 이용하는 방법은 필자가 이 곳에서 예로 들었던 것처럼 palette로 표현된 prototype 객체를 저장하는 클래스와 이 저장 클래스에 객체를 넣는 기능을 가지는 클래스로 나누어 구현하는 것이다. 그 외의 나머지 부분은 이 곳의 예와 같다.

이 패턴의 저자들인 GoF 들이 이 패턴에 대해서 밝히고 있는 의도(intent)로 Prototype 패턴에 대한 이야기를 줄이겠다.
 

의도(intent)

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype

cloning이 가능한 객체(프로토타입 객체)를 복사 함으로써 새로운 객체를 생성한다.

6.  관련 패턴
 

이 패턴과 관련이 있다고 저자들이 이야기하기로는 필자가 내용 중에도 언급했듯이 Abstract Factory 패턴[2]과 거의 대등하게 상용될 수 있고, 그 외의 관련 패턴으로는 Composite 패턴[2]과 Decorator 패턴[2]을 많이 사용하는 소프트웨어 디자인에서 함께 사용되면 많은 효과를 볼 수 있다고 한다. Composite 패턴과 Decorator 패턴에 대해서는 나중에 기회가 되면 살펴보기로 하자.
 
 

7.  맺음말
 

이 번호에는 객체의 타입 정보가 없이도 객체를 생성할 수 있는 Prototype 패턴에 대해서 알아 보았다. 역시 또, 객체 생성에 대해서 이야기를 해 보았다. 혹자는 객체 생성만 해도 참 할 말이 많구나 하고 느꼈을 지도 모르겠다. 그만큼 객체 생성에 대한 이해는 객체지향 프로그래밍의 기본이 된다고도 감히 말해 볼 수 있을 것 같다. 도움이 되었는지 모르겠다.

이 번호의 글을 읽으면서, 어 떤 독자는 객체만 생성하면 모든 것이 끝나느냐? 생성된 객체가 주어진 일을 다 끝내고 나서는 어떤 처리 방법이 있어야 하지 않느냐? 하고 의문을 가질 수도 있을 것이다. 필자도 그렇게 생각한다. 컴퓨터의 한정된 자원을 생각한다면 무한이 필요한 객체만 생성할 수는 없다. 나중 뒷처리를 어떻게 할 것인가도 아주 중요한 사항이다. 다음 호에는 object destruction에 대한 부분에 대해서 언급한 Object Lifecycle Pattern[4]에 대해서 이야기를 해 보려 한다. 기대해 주기 바란다.
 
 
 

참고 문헌

[1] Pattern languages of Program Design 3, edited by Robert Martin, Dirk Riehle, Frank Bschmann, Addison-Wesley, 1998 

[2] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,  Design Patterns, Elements of Resuable Object-Oriented Software,  Addison-Wesley, 1995 

[3] Setrag Khoshafian, Razmik Abnous, Object Orientation, 2nd, John Wiley & Sons, Inc., 1995

[4] David L. Levine, Christopher D. Gill, Douglas C. Schmidt, Object Lifecycle Manager A complementary Pattern for Controlling Object Creation and Destruction, PLoP 1999 conference
 
 
 

(글 후기 )

2000년 4월은 pattern에 대한 글만 쓰다가 다 보낸 느낌이다. pattern에 지대한 관심을 가지고 있는 독자들은 알고 있을 거라 생각을 하는데, 2000년 PLoP 컨퍼런스가 8월 13일에 열리고, 이 컨퍼런스의 논문 마감일은 5월 8일이라는 것을. 작년부터 이 컨퍼런스에 논문을 내리라 생각을 가지고 있다가 올 4월에 실천에 옮겼다. pattern writing에 대해서 참 많은 것을 느끼게 한 과정이었다. 나중에 시간이 나면 올 4월의 경험을 한 번 이야기 했으면 좋겠다. 이 번호에 필자가 쓴 pattern을 공개할 생각을 가지고 있었는데, 아직 정리가 되지 않은 관계로 다음 호로 미룬다. 다음 주 월요일이 어버이 날인데..  논문 마무리 일이 남아서 주말에 집에 갈 수 있을지 잘 모르겠다.