디자인 패턴(3) - 객체 생성의 또 다른 방법

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

객체지향 뉴스레터 2호에서부터 본격적인 패턴에 대한 이야기를 했다. 혹자는 도움은 되었는데 많은 내용이 없어서 좀 실망했다는 메일을 필자에게 보내주기도 했다. 사실 패턴에 대한 구체적인 내용만으로는 별 내용이 없는 것이 사실이었다. 구지 변명을 하자면 그 이유는 이렇다. 지난 호에 잘 알려진 패턴하나만을 가지고 이야기를 한 것은 필자의 게으름도 있었지만, 어는 정도 의도적이었다. 한 번에 여러 가지 패턴을 이러쿵 저러쿵 이야기를 하면 패턴이 무엇이냐에 대한 구체적인 이야기를 하고 넘어가야 하는 시점에서 그 핵심이 흐려질 수 있다는 생각에서였다. 본격적인 이야기를 시작하는 것이므로 첫 호에 둥그렇게 이야기한 패턴이 실재로 이런 것이라는 것을 못박고 싶은 욕심이 있었기 때문이었다.  패턴에 대한 이야기는 많이 들었는데 구체적으로 그 것이 무엇을 의미하는지 궁금해왔던 분들에게 도움이 되었는지 모르겠다. 

이 번호부터는 패턴이 무엇이냐에 답하기 위한 관점에서 글을 진행하기 보다는 필자가 지난 호에서 개인적인 패턴 선택의 기준인 ‘객체지향 프로그래밍 언어를 사용하여 시스템을 개발하고 있는 일반적인 개발자가 일상적으로 볼 수 있는 또는 필요로 하는 것들 중에서 디자인 패턴으로 정리되어 있는 것’에 부합된다고 생각되는 것들을 골라서 그 의미를 하나하나 파악해 가도록 할 예정이다. 이렇게 함으로써 이 분야의 경험이 많은 독자들이나 그렇지 않은 독자들이 나름대로 객체지향적인 시스템 디자인에 깊은 통찰(?)을 얻을 수 있을 것으로 기대한다. 여기엔 필자도 포함된다. ^(^ 

지난 호에는 객체 생성에 대한 패턴 중에 기본이 되는 것으로 Factory Method[1]에 대하여 알아보았다. 이 패턴을 이해하면 다른 관련 패턴들도 그리 어렵지 않게 이해할 수 있다는 것을 확인 할 수 있었을 것이다(관련 패턴으로 제가 열거한 것들을 읽어 보셨나요? ^(^). 이 번호에는 GoF 책에 소개되어 있는 객체 생성과 관련된 패턴들과는 좀 더 다른 시각에서 객체를 생성하는 방법에 대한 패턴을 알아보고자 한다. 아마 흥미로울 것이다.

1.  일반적인 객체 생성 과정 살펴보기

객체지향 패러다임의 특징을 지원하는 대중적인 프로그래밍 언어를 가지고 객체를 생성하는 경우를 생각해 보자. 이 들 언어는 클래스 기반의 프로그래밍 언어들로서 일반적으로 두 과정을 거쳐서 객체가 생성되게 된다. 먼저, 객체의 타입(Type)이 되는 클래스(class)를 정의한다. 그런 후에는 이 클래스를 가지고 해당 타입의 인스턴스(instance)인 객체(object)를 생성하는 과정을 거친다. 소스 코드를 보면 다음과 같은 모습을 보일 것이다.

class Oonews { … }
 

public class MainClass {
     …
     public static void main(String[] args) {
          …
          Oonews oonews_ = new Oonews();
          …
     }
     …
}

소스 1. 일반적인 객체 생성 과정
 

위의 소스를 보면 Oonews라는 클래스를 정의하고, 이렇게 정의된 클래스의 타입을 가지는 객체를 new라는 예약어(keyword)를 이용하여 명시된 타입의 객체를 생성하게 된다.

위의 과정을 좀 더 구체적으로 살펴보자. 프로그래머는 소스 1과 같이 프로그램을 만든 후에 컴파일(compile) 과정을 거친다. 컴파일 과정을 거친 코드는 일반적으로 실행 코드이며 이 코드를 실행시키면 실행 중에 프로그래머가 원하는 객체가 생성이 된다. 즉, 일반적으로 클래스 기반의 객체지향 프로그래밍 언어에서는 객체의 타입이 되는 클래스를 런타임(runtime)이 아니라 컴파일타임(compile time)에 결정이 된다. 따라서, 해당 객체의 타입을 바꾸어야 할 필요성이 있을 경우에는 해당 클래스의 소스를 고치고 컴파일 과정을 다시 거치게 된다. 

클래스 기반의  일반적인 객체지향 언어에서는 타입을 고치기 위해서 컴파일 과정을 다시 거치는 것이 일반적인데… 실행 중에 새로운 타입을 생성할 수 있다면 어떨까? TypeObject 패턴은 바로 그런 의문을 풀어줄 수 있는 패턴이다[2]. 이 패턴은 PLoP’96컨퍼런스(conference)에 발표된 것으로 GoF 책의 저자 중에 한 사람인 Ralph Johnson과 Bobby Woolf에 의해서 쓰여졌다(PLoP'96의 경우에는 인터넷 상으로 Proceeding을 공개하고 있지 않다. TypeObject 패턴에 대한 논문 원본은 참고문헌 2번에 나와 있다). 이런 방법은 컴파일 과정을 거치야 하는 방법과 비교해서 장단점이 분명이 있다. 우선 그런 점을 논하기 전에 어떻게 하면 그렇게 할 수 있는지 TypeObject 패턴을 통해서 알아보자. 흥미롭지 않은가?
 
 

2.  실행 중에 타입을 생성하자 - TypeObject 패턴

일단 궁금하니까 우선 그 구조부터 보자. TypeObject 패턴은 그림 1과 같다.

그림 1.  TypeObject 패턴

이 패턴 구조를 보고는 에게~~  하는 독자도 있을 것이다. 구조는 간단하지만 이 패턴은 실행 중에 타입을 생성할 수 있게 해 준다. 이제 이 번호의 본격적인 이야기를 시작해 보겠다. 
 

2.1 시나리오

TypeObject 패턴이 유용하게 사용될 수 있는 상황에는 어떤 경우가 있을까? 여기서는 이 패턴의 저자들이 설명하는데 이용했던 비디오 가게의 경우를 그대로 사용하도록 하겠다.

비디오 가게에서 비디오 테이프 관리를 쉽게 관리할 수 있는 시스템을 만들어 달라는 의뢰를 받았다고 가정해 보자. 자.. 이제 어떻게 하여야 하는가? 

이 시스템을 디자인 하는 데는 비디오 가게의 ‘비디오 테이프’를 나타내기 위하여 Videotape이라는 클래스를 필요로 할 것이다. 그렇다면 비디오 가게에서 취급하고 있는 모든 비디오 테이프를 나타내는 클래스를 만들 것인가? 이런 식으로는 문제가 효율적으로 해결되지 않는 다는 것을 경험 있는 독자들은 금방 알아차렸을 것이다. 그럼 이렇게 했을 경우의 문제점이 무었인가? 생각해보면 다음과 같이 두 가지의 커다란 단점이 있을 수 있을 것이다. 첫 번째로는 한 비디오 가게에서 취급하는 비디오들 사이에는 공통점이 많이 있어서, 컴퓨터 자원 낭비를 초래할 수 있다. 예를 들어 같은 이름의 영화를 담고 있는 비디오 테이프들은 ‘영화이름’, ‘영화등급’, ‘대여료’ 등에 관한 데이터는 똑같고, 해당 비디오 테이프의 ‘대여자’, ‘대여일자’ 등에만 차이를 보인다. 또 다른 문제점으로는 새로운 비디오 테이프가 들어왔을 경우에는 해당 비디오 테이프에 대한 클래스를 만들어서 다시 컴파일을 해 주어야 하는 문제가 있다. 

그럼 위와 같은 문제점을 해결하기 위해서는 어떻게 해야 할까? 위에서 문제가 되었던 같은 영화를 담고 있는 비디오 테이프 사이의 공통점을 해결하기 위한 방안으로 ‘상속(inheritance)’을 쉽게 생각할 수 있을 것이다. 그럼 객체지향 패러다임의 한 가지 커다란 특징인 ‘상속’을 이용하기 위해서, 우선 모든 비디오 테이프가 가지고 있는 속성을 가지는 Videotape이라는 클래스를 만들고 이 클래스를 상속하는 각 영화에 해당하는 클래스를 만든다. 예를 들어, ‘쉬리’와 ‘반칙왕’에 대한 비디오 테이프의 경우, Videotape을 상속하는  SwiriVTape, FoulkingVTape이라는 클래스를 만들어서 사용하는 것이다. 이렇게 함으로써 처음에 문제가 되었던 같은 데이터를 중복하여 사용하는 컴퓨터 자원 낭비를 어느 정도 줄일 수 있다. 그러나, 여전히 두 번째 문제는 해결할 수 없는 방안이다. 그 이유는 새로운 영화의 비디오 테이프가 들어오면 해당 영화에 대한 기존에 클래스가 없기 때문에 새로운 클래스를 만들어 컴파일을 다시 해 주어야 하기 때문이다.

문제를 해결하기위한 방안으로 생각해본 위의 두 가지 방안이 이 경우에 효율적으로 먹혀 들지 않는 이유는 무엇인가? 그 것은 이 문제에는 실행 중에 동적으로 변하는 부분이 있는데, 위에서 생각한 두 가지 방안에는 이에 대한 처리 부분이 없기 때문이다. 다시 말해서, 현실적으로 새로운 영화가 지속적으로 나오고 있는데, 코드는 이 문제를 컴파일 시간에 모두 해결하려는 시각으로 접근하고 있기 때문이다. (이 것을 영어식 표현으로는 hardcode 한다고 그러던데..) 그럼 동적으로 이런 문제를 해결하기 위해서는 어떤 식으로 시스텀을 디자인 해야 할까?  TypeObject 패턴이 바로 이런 문제에 해결책을 제시하고 있다.
 

2.2 인스턴스를 그들의 클래스로부터 해방시키자 !!

위에서 제시된 두 가지 디자인의 문제점은 동적으로 변하는 타입에 대한 처리를 할 수 없다는 것이었다. 이 문제는 그림 1의 TypeObject구조를 취하면 쉽게 해결된다. 그럼 타입이 런타임 시에 어떻게 바뀔 수 있는지 비디오 테이프 문제로 다시 돌아가서 생각해 보자.

위의 비디오 테이프에 대한 이야기에서 알 수 있었겠지만, 결국 비디오 테이프의 타입 속성으로 볼 수 있는 것은 그 비디오 테이프가 담고 있는 영화의 제목과 그 비디오 테이프의 대여료 정도로 볼 수 있고, 나머지 속성, 즉, 대여자, 대여 여부, 대여일 등은 특정 타입의 인스턴스로 볼 수 있다. 따라서, 그림 2와 같이 이 시스템을 디자인 하면 동적으로 변하는 타입의 문제를 해결할 수 있다. 그림 2의 클래스 다이어그램을 보면,  Movie라는 클래스와 Videotape이라는 두 개의 클래스로 이루어져 있다. Movie 클래스는 원하는 비디오 테이프의 타입을 나타내 클래스고, Videotape은 Movie 클래스에 의한 타입에 대한 인스턴스를 생성하는 클래스다.

그림 2. TypeObject 패턴을 이용한 비디오 테이프 처리를 위한 디자인

이를 좀더 구체적으로 설명하여 보겠다. 위와 같은 디자인으로 객체를 생성하면 그림 3과 같이 된다. 먼저 ‘쉬리’라는 새로운 영화의 비디오 테이프가 가게에 도착했다고 하면, 이에 대한 타입을 만든다. 이제는 새로운 클래스를 만들어 프로그램을 다시 컴파일 하는 것이 아니라, 그림 2의 Movie 클래스로부터 title은 swiri로 대여료는 1500원인 속성을 가지는 aMovie0001이라는 객체를 동적으로 생성한다. 그런 다음에는 가게에 들어온 쉬리 비디오 테이프의 개수 만큼의 Videotape 객체를 생성하는데, 이 들 객체는 모두 쉬리 타입의 객체를 가리키는 aMovie0001라는 type 속성을 가진다. 그림 3은 이렇게 생성된 비디오 테이프 객체가 두 개 있고, 각각 ‘이승일’과 ‘이민규’에게 대출되어 있는 상태를 나타내고 있다.

그림 3. 그림 2의 디자인을 이용한 객체 생성의 예

잘 이해가 되었는지 모르겠지만, TypeObject 패턴은 타입을 생성하는 클래스와 인스턴스를 생성하는 클래스가 따로따로 있도록 되어 있다. 따라서, 런타임 중에 필요한 타입을 생성할 수 있으며, 생성된 타입의 인스턴스는 인스턴스를 생성하는 클래스에 의해 생성되어 자신에게 적절한 타입 객체의 포인터를 가짐으로써 자신의 타입을 동적으로 나타낼 수 있게 된다. 위에서 예로 든 비디오 테이프의 경우에 새로운 영화의 비디오가 들어오면 타입 클래스인 Movie 클래스를 이용하여 새로운 타입의 영화를 생성하고, 이에 대한 비디오 테이프의 개수만큼의 인스턴스는 인스턴스를 생성하는 클래스인 Videotape 클래스를 통하여 생성된 후에 자신의 타입 인스턴스를 가리키는 포인터를 속성으로 갖는다. 결과적으로 TypeObject 패턴을 이용하면 위에서 문제가 되었던 컴퓨터 자원의 낭비 문제,  동적으로 타입을 생성하지 못했던 문제를 모두 해결할 수 있는 디자인 해법으로 볼 수 있다.

이 글의 처음에 흥미로울 것이라고 그랬는데, 이 글을 읽은 독자가 어떻게 느꼈는지 궁금하다. 사실 TypeObject 패턴은 동적으로 객체의 타입을 결정할 수 있게 하는 힘을 가지고 있지만, 그만큼 구현할 경우에 신경 써야 할 것이 많다. 왜냐하면, 일반적으로 프로그래밍 언어에서 해 주어야 할 타입에 대한 결정을 프로그래머가 직접 해 주어야 하기 때문이다. 하지만, 이 패턴을 적절한 곳에 잘 활용하면 기대 이상의 좋은 시스템을 만들 수도 있다는 생각을 한다.

2.3  동적 타입 변경 - 그 이상...

사실 이 패턴은 우리에게 많은 것을 이야기해 주고 있다. 그림 1에 나타나 있는 것은 그냥 두 개의 클래스로 보일 수도 있다. 하지만 지금까지 보았듯이 이 단순한 클래스 두 개를 가지고 동적으로 타입을 변경할 수 있는 일을 해 낸 것이다. 참 놀랍지 않은가? 사실 이 패턴에 대해서  할  이야기가 많이 남았지만, 여기서 줄이기로 하고 이 패턴의 저자들이 밝히고 있는 이 패턴의 의도(intent), 핵심(keys)를 정리하는 것으로 마무리를 지을려고 한다.  관심이 있는 독자들은 참고문헌[2]의 책을 사서 자세히 읽어 보기 바란다. 필자가 거짓말을 하고 있을지도 모르니까.  ^(^
 

의도(intent)

A Type Object decouples instances from thier classes so that those classes can be implemented as instances of a class. Type Object allows new classes to be created dynamically at runtime, lets a system provide its own type-checking rules, and can lead to simpler and smaller systems.

TypeObject 패턴은 인스턴스들를 해당 인스턴스들의 클래스로부터 분리시킴으로써 그 클래스들이 하나의 다른 클래스의 인스턴스들로 구현될 수 있도록 한다. TypeObject 패턴은 새로운 클래스들을 런타임시에 생성될 수 있도록 해 줌으로써 하나의 시스템이 자신의 타입 결정 규칙을 제공할 수 있게 한다. 따라서, 이 패턴을 이용하면 단순하고 작은 시스템을 구성할 수 있다.

핵심(Keys)

• Two classes, a type class and an instance class.
• The instance class has an instance variable whose type is the type class
• The instance class delegates its type behavior to the type class via the instance variable.

• 타입 클래스와 인스턴스 클래스의 두 개의 클래스로 이루어져 있다.
• 인스턴스 클래스는 자신의 타입을 가리키는 변수를 가진다.
• 인스턴스 클래스는 자신의 타입에 속한 행위에 대한 메소드(method)는 타입을 나타내는 변수를 통하여 위임시킨다.
   

2.4 관련 패턴

이 패턴의 저자들은 관련 패턴으로 Strategy[1], State[1], Reflective Architecture[3], Bridge[1], Decorator[1], Flyweight[1], Prototype[1] 을 열거했는데,  여기서 각 패턴들과 이 번호에서 소개한 TypeObject 패턴과 어떤 면에서 관련이 있는지를 이야기하는 것만으로도 여러 호에 걸쳐서 이야기 거리가 될 것 같다. 그래서, 지금 생각은 이 중에 재미있는 것을 하나 골라서 다음 호에 안주거리로 삼으면 어떨까 생각해 본다. 이 번호에 본 TypeObject 패턴의 다른 면도 볼겸해서....

3. 맺음말

우리가 좋은 시스템을 디자인 하기 위해서는 어떻게 해야 할까? 그냥 유명한 작가가 쓴 C++나 Java 프로그래밍언어 책만을 무식하게 100독하면 그 무언가가 깨쳐질까? 아니면 그냥 아무 프로그램이나 막 만들어 보는 것일까? 그러다 보면 꽁수가 늘어서 휼륭한 시스템을 디자인하고 구현할 수 있을까?  아니면 훌륭한 개발도구를 마련해서 사용법에 아주 익숙해져 버리는 것일까?  물론 어느 정도는 가능할 것이다. 그러나, 이런 방법으로는 프로그래밍적인 능력은 향상시킬 수 있을지 몰라도 시스템 디자인 능력에는 많은 한계가 있을 것이다. 

개인적으로는 시스템 디자인에는 프로그래밍 능력 그 이상이 필요하다고 생각하고 있다. 필자가 개인적으로 패턴을 보고 놀랐던 것은 여기서 설명된 이런 종류의 간단한 클래스 두 개가 소프트웨어적인 컴퓨터 시스템의 성능에 커다란 영항을 키칠 수 있다는 것을 느꼈기 때문이었다. 이 글을 읽는 독자는 어떻게 생각 하는가? 

참고 문헌

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

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

[3] F.Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, 
      Pattern-Oriented Software Architecture - A Study of Patterns. 
      New York, Wiley and Sons Ltd., 1996
 
 

(글 후기 )

필자의 실수 

사실 이 글을 쓰고 있는 이유는 필자가 일방적으로 많은 사람을 대상으로 패턴에 대한 교리(?)를 전파하여 어떤 무엇을 얻으려는 것이 아니라, 같은 관심사를 가지는 사람들 사이에서 서로의 생각을 나누고 자신의 생각을 다듬으려는 의도가 큽니다. 이런 관점에서 필자가 지난 달에는 커다란 실수 하나를 했습니다. 지난 호의 필자의 글을 읽고 이에 대한 토론을 유발하는 글을 백영우씨가 ‘묻고 답하기’란에 올려 주셨는데 필자는 이에 대해 무슨 교주인양 태도를 보이는 답을 쓰고 말았던 것입니다. 처음에는 아무 생각이 없었는데 시간이 지난 지금에 와서야 참 바보 같은 짓을 했다는 것을 깨달았죠. 백영우씨를 포함해서 이 글을 읽으시는 분들에게 참 죄송스럽다는 말을 드립니다. 앞으로는 자유로운 토론이 이루어질 수 있도록 주의를 기울이겠습니다. 그리고, 현재는 저 혼자만 패턴에 대한 토론 주제(저의 글)를 매달 띄우고 있는데..  혹시 패턴에 대해서 글을 써 주실 다른 분 안 계세요? 그럼 패턴에 대한 내용도 더 풍성해지고, 이에 따라서 패턴에 관심을 가지고 있는 우리들의 생각도 더 다듬어질 수 있을 거란 생각이 드는데..  ^(^
 

UML에 대한 정리를 첨부하지 않은 이유..

현재 객체지향 뉴스레터에는 플라스틱 소프트웨어의 심원도씨가 UML에 대해서 글을 써주시고 계십니다. 개인적으로 패턴에 사용되는 수준의 UML을 정리하고 있었는데, 심원도씨의 글과 중복된다는 생각에 제가 정리한 것은 여기에 포함시키지  않기로 결정을 내렸습니다. UML에 대한 구체적인 내용은 심원도씨의 글과 http://www.uml.co.kr/ 사이트를 참고하시면 충분하리라 생각하고 있습니다.
 

소스 코드 사용 규칙

제가 쓰고 있는 글에서 사용하는 Java 언어에 대한 소스 코드 사용 규칙에 대한 문서를 객체지향 뉴스레터의 1호 글 후반부에 첨가 시켜 놓았습니다.