디자인 패턴(2) - 수박 맛을 보자!!
이승일
E-mail:gaialee@icu.ac.kr
한국정보통신대학원대학교
Homepage:http://www.icu.ac.kr/
1. 수박을 자르기 전에…
지난 호에는 수박(디자인 패턴) 맛을 보여주지는 않고, 그 맛이 이렇다 저렇다 그랬다. 이 번 호에는 그 맛이 어떤지 보여주려고 맛있는 놈을 고르기 위해 시장을 여기 저기 돌아다녔다(아이고 다리야~~). 이 맛에 많은 사람들이 감동해야 하는데..
이 번호의 이야기를 시작하기 전에 두 가지 명확하게 하고 넘어가야 할 것이 있다.
- 예제의 소스 코드는 자바(Java) 프로그래밍 언어를 이용할 것이다.
프로그래밍 언어 사용에 있어서 자바 언어를 선택한 이유는 현재 대중적인 프로그래밍 언어 중에서 객체지향의 특징을 가장 많이 가지고 있다고 생각하기 때문이다. (우리나라의 프로그래밍 현실에서 대중적인 객체지향 언어는 C++와 Java 언어를 들 수 있을 것이다.)
- 클래스 다이어그램(class diagram)은 Unified Modeling Language(UML)을 이용하여 표현할
것이다.
자바 언어에서 객체를 생성하기 위해서는 클래스를 먼저 정의하여야 한다. 클래스는 객체의 타입(Type)이 되고 이 클래스를 이용하여 해당 타입의 객체를 생성하게 된다. (너무 당연한 이야기를 한다고 생각하지 말라. 객체지향 언어 중에는 클래스 개념이 없는 것도 있다.) 객체지향 시스템 디자인을 하기 위해서는 필요한 클래스들 사이의 관계를 명시해야 하는 과정, 즉, 클래스 다이어그램을 만들 필요가 있는데, 이 경우에 유용하게 사용될 수 있는 것이 UML이다. UML에 대한 구체적인 이야기는 UML 관련 섹션에서 얻기 바란다.
위에서 이야기한 것처럼 자바 언어와 UML을 사용하기 위해서 자바 언어 사용에 대한 코딩 규칙(coding rule)과 간단히 UML을 정리하여 “코딩 규칙과 UML 다이어그램”이라는 제목으로 다른 문서를 만들고 있다. 사실 이 번호에 첨부 시킬 계획을 가지고 있었는데, 여러 가지 사정으로 그러하지 못했다. 문서가 완성되는 대로 디자인 패턴 섹션에 첨부하여 놓겠다.
자꾸 수박, 수박하니 내가 수박에 관련된 이야기를 하고 있는 것 같은 착각이 든다. 이제 수박에 대한 이야기는 그만 하고 본격적인 패턴 이야기를 해 보겠다.
혹자는 99년 3월 달을 기준으로 “현재 30여 개 정도의 패턴이 발표되어 있다”라고 하였는데,이 것은 잘 모르고 한 이야기다[마이크로소프트웨어 1999년 3월호, 디자인 패턴 특집기사, p. 254]. 1998년 미국의 PLoP98 컨퍼런스(conference)에 발표된 패턴만 하더라고 30여 개가 넘는다. 아마도 GoF 책[1]에 나와 있는 패턴과 시중에 나와 있는 책에 기술되어 있는 것이 전부인 것으로 생각한 모양이다. 어쨌든, 지금까지 공식적으로 발표된 패턴의 수는 지난 호에서도 이야기 했듯이 수 백 가지가 된다. 이 중에서 패턴의 의미를 알리기에 좋은 것을 찾는 다는 것은 쉬운 일이 아니다. 개인적으로 “객체지향 프로그래밍 언어를 사용하여 시스템을 개발하고 있는 일반적인 개발자가 일상적으로 볼 수 있는 또는 필요로 하는 것들 중에서 디자인 패턴으로 정리되어 있는 것”을 패턴 선택의 기준으로 삼고 있다. 이와 같은 기준을 새운 배경에는 디자인 패턴의 첫 호에서 언급했듯이 디자인 패턴은 새로운 것을 의미하는 것이 아니고, “프로그래머의 경험”을 의미하는 것이기 때문이다. 따라서, 선택되는 패턴은 일반적으로 객체지향 언어를 사용하는 프로그래머가 쉽게 접할 수 있는 내용이어야 하고 그 중에서도 실질적으로 도움이 많이 될 수 있어야 한다고 생각했다. 이 번호에서는 위에서 언급한 기준에 적합한 것 중에서 그 첫번째로 Factory 패턴을 골라 보았다.
2. 잘 익은 수박 하나 ? - Factory 패턴
이 번호에 소개하려고 하는 Factory 패턴은 공식적으로 “Factory Method”로 표기되어 있으며, 객체 생성에 관한 내용을 담고 있다[1]. 객체 생성은 일반적인 프로그래머들이 객체지향 언어를 이용하여 프로그래밍을 할 때 늘상 하고 있는 일이기 때문에 간과되어질 수도 있지만, 객체지향적으로 디자인된 시스템은 결국 객체의 생성과 소멸 그리고 생성된 객체들 간의 메시지 전달을 의미하므로 객체의 생성이 그 근본이 된다고 볼 수 있다. 이런 의미에서 객체를 어떻게 하면 효율적으로 생성할 수 있는지에 대한 것을 한번쯤은 깊이 생각해 볼 필요가 있는 것이다.
Factory 패턴은 오랜 기간동안 객체지향 시스템 디자이너들이 객체 생성에 대한 고민을 한 끝에 일반적인 시스템에서 객체 생성시에 자주 등장하는 디자인을 패턴화 시키고 이름은 붙여 놓은 것으로 이해하면 될 것이다. 따라서, 숙련된 시스템 디자이너에게는 Factory 패턴이 너무나 익숙한 내용일 것이고, 경험이 적은 개발자에게는 객체 생성에 대한 좋은 방법 하나를 익히는 기회가 될 것으로 생각한다.
2.1 객체생성의 두 가지 방법
여러분들이 객체지향 프로그래밍 언어를 가지고 필요한 객체를 생성하는 과정을 생각해 보라. 지금까지 자신이 객체를 생성하는데 사용한 과정이 크게 두 가지라는 것을 발견하게 될 것이다. 먼저 객체 생성의 주체가 되는 객체에서 다른 객체를 직접 생성하는 것이 하나요, 다른 하나는 객체 생성의 주체가 되는 객체가 생성하려는 객체를 직접 생성하는 것이 아니라 다른 객체에 해당 객체 생성을 의뢰하는 것이다.
두 가지 객체 생성 과정을 이해하기 위해서 “번역기” 시스템을 디자인 하여 보자. 번역기 시스템이란 사용자가 영어와 일어 두 가지 언어 중에서 하나를 선택하고 우리나라 문장을 넣으면 그 문장에 대한 해당 언어로 번역해 주는 시스템이다. 이 시스템을 위에서 구분지은 객체 생성에 대한 두 가지 과정으로 나누어서 디자인하여 보고, 이 두 가지 디자인이 각각 어떤 차이를 보이는지 살펴보겠다. 여기서 예로 든 번역기 시스템에 대한 아이디어는 [3] 문서에서 얻었다.
2.2 직접 객체를 생성하는 경우
번역기를 만들기 위해서 그림 2와 같은 구조로 영어 번역기와 일본어 번역기를 디자인 하였다고 하자. 그림 2와 같은 디자인의 장점은 인터페이스(아래 첨부 글을 보기 바란다)를 이용하여 각 번역기를 사용하는 클라이언트와 각 번역기와의 의존성을 일부분 제거했다는 것이다.
그림 2. Translator 인터페이스를 이용한 번역 객체의 이용
그림 2의 디자인을 토대로 번역기 시스템의 클라이언트 부분의 구현을 한다면 소스 1과 같은 코드가 될 것이다.
public class TranslatorClient {
…
private Translator tr_;if(language == ENGLISH) {
tr_ = new EnglishTranslator();
} else if (language == JAPANESE) {
tr_ = new JapaneseTranslator();
}
…
translatedSentence = tr_.translate(inputSentence);
…
}
소스 1. 그림 1의 구현 소스
번역기를 위한 그림 2와 같은 디자인은 그런대로 쓸만하다. 그 이유는 이미 이야기 했듯이 인터페이스를 클라이언트와 각각의 번역기 사이에 두어서 소스 1 중에서
translatedSentence = tr_.translate(inputSentence);
처럼 사용되는 번역기에 상관없이 같은 메소드를 호출한다는 것이다. 따라서, 이 경우 해당 번역기의 소스가 수정되더라도 클라이언트의 메소드 호출부분에 대한 소스는 고칠 곳이 없다. 그러나, 이 디자인에는 한 가지 아쉬운 부분이 남아 있다. 바로 해당 번역기를 생성하는 부분이다.
그림 2와 같은 디자인으로는 필요한 번역기의 객체를 생성하기 위해서 그 해당 번역기의 타입을 알아야 하는 문제점이 남아 있다. 즉, 소스 1에서
if(language == ENGLISH) {
tr_ = new EnglishTranslator();
} else if (language == JAPANESE) {
tr_ = new JapaneseTranslator();
}
처럼 필요한 번역기의 객체를 생성시키려면 굵게 표시된 부분처럼 구체적인 번역기의 타입을 알아야 한다. 이 부분이 발생시키는 문제점은 객체 생성에 있어서, 클라이언트와 번역기 사이의 의존성을 제거하지 못했다는데 있다. 다시 말해서, 지금은 영어 번역을 위해서 사용하는 객체가 EnglishTranslator이지만, 나중에 시스템을 업그레이드 할 경우 다른 타입의 번역기를 사용하게 되면 이 부분을 바꾸어 주어야 하는 것이다. 직접 해당 객체를 생성할 때 발생하는 이러한 의존성 문제를 해결하기 위해서 객체 생성을 다른 객체에 의뢰하는 디자인을 생각하게 된 것이다. 이제 그 이야기를 할 차례다.
2.3 다른 객체에 필요한 객체의 생성을 의뢰하는 경우
위에서 지적한대로 필요한 객체를 생성하는 곳에서 발생하는 객체 사이의 의존성을 없애기 위해서 생성에 대한 부분을 따로 떼내어
생성만 전담하는 객체를 하나 더 만드는 방법을 사용한다. 그림 3은 객체 생성에 따른 의존성 문제를 해결한 디자인이다.
그림 3. 객체 생성을 다른 객체에 의뢰하는 경우의 디자인 - Factory Method
그림 2의 디자인과 그림 3의 디자인을 비교해 보면, 달라진 부분이 하나 있다. 객체 생성을 전담하는
TranslatorFactoryImpl 객체를 하나 만들어 클라이언트가 Translator를 통해서 하던 번역기 객체 생성 일을
맡겼다는 것이다. 개선된 번역기 시스템의 디자인에 대한 클라이언트 부분의 소스 코드는 소스 2와 같이 수정이 가해질 것이다.
public class TranslatorClient {
…
private TranslatorFactory tf_;private Translator tr_;
…
tf_ = new TranslatorFactoryImpl();if(language == ENGLISH) {
tr_ = tf_.getEnglishTranslator();
} else if (language == JAPANESE) {
tr_ = tf_.getJapaneseTranslator();
}
…
translatedSentence = tr_.translate(inputSentence);…
}
소스 2. 개선된 번역기 시스템의 클라이언트 소스
소스 2를 보면서 클라이언트 구현부가 더 복잡해 졌다고 투덜되는 독자도 있을 것이다. 그러나, 잘 뜯어 보면 이제는 객체 생성 부분에 남아 있던 의존성 부분까지도 제거 했음을 볼 수 있다. 객체 생성 부분에 남아 있던 의존성 부분이 제거된 부분은 소스 2에서 다음 부분이다.
if(language == ENGLISH) {
tr_ = tf_.getEnglishTranslator();
} else if (language == JAPANESE) {
tr_ = tf_.getJapaneseTranslator();
}
위에서 굵은 글씨로 되어 있는 부분이 예전에는 해당 번역기 객체의 타입이 명시되어있던 부분이다. 이 부분이 이제는 생성 책임을 맡고 있는 객체의 인터페이스로 바뀜으로 해서 번역기가 바뀌는 것에 대한 의존성을 완전히 제거되었다. 즉, 번역기 시스템은 기본적으로 번역을 하는 시스템이고 따라서 TranslatorFactory, Translator 인터페이스를 통해서 정의된 기능에 대한 수정이 가해지는 일은 거의 없을 것이다. 업그레이드를 위해서 수정이 가해지는 일이 발생한다면, 그것은 번역 정도의 향상을 위한 알고리즘의 변화나 번역기 교체에 대한 것이므로 그림 3과 같은 디자인으로 번역기 타입과 해당 번역기의 메소드 사용에 대한 의존성을 모두 없앤다면 유지, 보수가 매우 높은 시스템이 될 것이다.
앞에서도 이야기했지만 그림 3과 같은 시스템 디자인은 객체의 생성 문제를 효과적으로 해결할 수 있는 구조여서 경험이 많은 개발자들은 알게 모르게 이러한 디자인을 자신이 개발하고 있는 시스템에 사용하여 왔다. 이런 경험에 이름을 붙여서 정리해 놓은 것인 Factory Method다. GoF 책에 기술되어 있는 이 패턴의 의도는 다음과 같으며, 이 패턴 구조를 일반화 시켜서 그림 4와 같이 정리하였다(필자가 UML 버전으로 바꾸었다).
의도(Intent)
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
객체 생성에 대한 인터페이스를 정의한다. 그러나, 생성할 객체에 대한 클래스의 선택은 이 인터페이스를 구현(Implementation)한 클래스가 결정하도록 한다. Factory Method는 객체 생성에 대한 책임을 인터페이스를 구현한 클래스에 전가한 것이다.[1]
그림 4. Factory Method
2.4 관련 패턴
패턴으로 정리되어 있는 것들을 보면, 서로 밀접하게 연관되어 있는 것들도 있고 그렇지 않은 것들도 있다. 시스템 디자인 시에 자주 발생하는 것들을 패턴으로 정리하는 양태는 크게 세 가지로 나타나는 것을 확인 할 수 있다. 지금까지 발견하지 못했던 새로운 내용을 패턴으로 정리하는 경우가 그 하나고, 기존의 것을 수정하거나 포함하여 하나의 패턴으로 정리하는 경우가 두 번째다. 마지막으로는 기존에 패턴으로 정리되어 있던 것을 이름을 달리하여 사용하는 경우가 있다[4]. 여기서 소개한 Factory Method도 이와 마찬가지로 다른 패턴들과 연관되어 있다. 이 패턴과 관련되어 있는 것으로는 Abstract Factory, Template Methods, Prototype 등과 연과 되어있다[1]. 여기서 Abstract Factory 패턴은 Factory 패턴과 아주 밀접하게 연관되어 있다. 이야기를 전개해 나가면서 Abstract Factory 패턴도 건드려 볼까 생각을 했었는데, 구지 그럴 필요가 없다고 생각을 했다. 독자들이 한 번 Abstract Factory 패턴의 내용을 직접 보는 것이 더 도움이 될 것 같다고 생각을 했다. 읽어보면 알겠지만 그리 어렵지 않게 그 내용을 이해하여 활용할 수 있을 것이다.
3. 맺음말..
이 글을 읽는 독자들 중에서 어느 정도의 수준에 이르러 있는 프로그래머들은 지금까지 Factory Method라는 이름으로 포장된 내용을 이미 잘 이해하고 있으며, 자신이 참여하고 있는 프로젝트의 구현부에서 이미 많이 사용한 경험을 가지고 있을 수도 있을 것이다. 그러나 필자가 구지 이런 내용을 여기서 첫 번째 디자인 패턴으로 소개한 이유는 이 글의 초반부에서도 언급했듯이 “객체지향 프로그래밍 언어를 사용하여 시스템을 개발하고 있는 일반적인 개발자가 일상적으로 볼 수 있는 또는 필요로 하는 것들 중에서 디자인 패턴으로 정리되어 있는 것”을 패턴 선택의 기준으로 삼는 것이 의미가 있다고 판단했기 때문이다.
Factory 패턴은 보고 이 글을 읽는 독자가 디자인 패턴에 대하여 어떤 느낌을 가지게 되었는지 궁금하다. ‘뭐 별거 아니군’ 하는 독자도 있을 것이고, ‘야 바로 이거야’ 하는 독자도 있을 것이다. 필자의 경우는 후자에 속했었다. 필자가 후자에 속한 이유는 다음과 같다. 객체지향 패러다임은 다형성(polymorphism)의 성질이 있어 재사용성을 높일 수 있다고 떠들어 대는 수많은 사람들과 책들을 보았고, 필자는 다형성을 이해하기 위해서 노력하고 얼마간은 이해하는데 성공하기도 했다. 그러나, 다형성을 실재로 잘 이해해도 실질적으로 객체지향 시스템을 디자인할 경우에 이를 구체적으로 사용하는 데는 한계가 있었다. 그러던 중에 디자인 패턴을 보았고, 디자인 패턴은 나에게 달콤한 꿀을 주었다. 첫 호에서도 언급했듯이 디자인 패턴은 객체지향 시스템 디자인시의 재사용성 실질적으로 제공할 수 있다는 것을 보여 주었기 때문이다.
나는 디자인 패턴에 관심이 있는 많은 사람들이 이 글을 읽고 ‘어쩌구’, ‘저쩌구’ 해 주었으면 좋겠다. 그 이유는
두 가지다. 하나는 이 글을 읽는 사람들에 대한 분위기를 파악하는 것이 하나이고, 다른 하나는 내가 잘 못 이해하고 있는 부분에 대한
고침을 받기 위해서다. 그리고, 개인적으로는 이 글이 우리나라의 디자인 패턴 활성화에 기폭제가 되었으면 하는 큰 바람이
있다. 다음 호에는 어떤 것을 가지고 이야기를 풀어갈지 기대해 주샾!!
^(^
참고 문헌
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Elements of Resuable Object-Oriented Software, Addison-Wesley, 1995
[2] Mark Grand, Patterns in Java, volume 1, Wiley, 1998
[3] Nigel Warren, Philip Bishop, Java in Practice, Design Styles and Idioms for Effective Java, Addison-Wesley, 1999
[4] Pattern languages of Program Design 3, edited by Robert
Martin, Dirk Riehle, Frank Bschmann, Addison-Wesley, 1998
(첨부 글)
이 글은 “인터페이스(Interface)”에 대한 이해가 없이는 이해하기가 쉽지 않을 거란 생각이 든다. 하지만 인터페이스란 주제가 그리 쉽게 되어질 수 있는 것은 아니라고 생각한다. 이 글을 쓰기 시작한 초기에는 이런 점에 주의를 기울이지 못했다가 글을 쓰기 시작하여 마감일이 다가오면서 그 중요성이 느껴지기 시작했다. 개인적으로도 한 번 정리하고 넘어가고 싶은 욕심이 있는 주제다.
개인적으로는 인터페이스에 대한 것이 어느 정도 잘 이해하기 위해서는 “Abstraction”, “Abstract Data Type”, “Type 이론” 등에 대한 이해가 선행되어야 할 거라 생각을 하고 있다. 이 부분에 대한 충분한 준비를 하지 못한 점에 대해서 이 글을 읽는 분들에게 미안한 마음이 많다. 새로운 주제가 생겼으니, 이 부분에 대한 것을 다음 호에는 충분히 반영하여 관련 내용에 대한 글을 실을 수 있도록 노력하겠다. 여기서는 자바 언어를 이용하여 코드 구현이 되어 있으니, 간단하게 이해할 수 방도로 자바 프로그래밍 언어를 설명해 놓은 책의 “interface” 관련 내용을 참고 하기 바란다.
(글 후기)
객체지향 뉴스레터의 “묻고 답하기”란에 유화식님이 디자인 패턴에 대해서 한글로 된 참고 문서나 사이트를 추천해 줄 것을 요청한 적이 있었습니다. 이에 대해서 저는 없다라고 답을 해 주었는데, 서영준님이 마소 3월호에 디자인패턴 특집기사가 있다는 정보를 알려 주셨더군요. 그래서, 곧 확인 작업에 들어갔습니다. 개인적으로 모르고 있었던 사실이었거든요. 마소에 실린 글을 보고 한 마디 해야 겠기에 여기에 이리 글을 적는 것입니다.
혹시 이 글을 읽는 분들 중에 디자인 패턴에 관심이 있으시다면 제가 참고문헌 [2]로 달아 놓은 “Patterns in Java”라는 책을 아실 겁니다. 마소에 소개 되어 있는 패턴과 관련된 내용은 거의 이 내용을 그대로 따랐으며, 클래스 다이어그램도 이 책의 것을 거의 그대로 사용했더군요. 다른 책의 내용을 참고한다는 측면에서는 아무 문제가 없습니다. 여기서 문제는 어느 책을 참고 했다는 이야기도 없고 그대로 옮겨 놓은 클래스 다이어그램들도 잘 못 표기되어 설명과 다르게 되어 있다는 것입니다. 이 것은 너무 무책임한 처사가 아닌가 생각을 해 봅니다. 우리 나라의 개발자들이 가장 많이 본다는 전문 잡지에서 이런 식의 내용을 아무 생각 없이 지면에 실었다는 것이 도데체가 납득이 가지 않더군요. 자신의 이해를 바탕으로 씌여 졌다기보다는 다른 사람의 생각을 그대로 자신의 것인 양 사용해서, 한 책에서 주장하고 있는 내용을 그 것이 전부인 것처럼 이야기하는 어처구니 없는 이야기 전개를 하고 있는 것이죠. 그러니 잘 모르는 독자들은 그 내용에 읽는다면 많은 혼란의 소지가 있을 것입니다.
사실 객체지향 뉴스레터를 발간하는 저희들도 이런 문제에 아주 조심을 해야 할 것이란 생각을 하고 있습니다. 제가 글을 쓰면서도 반복적으로 말씀을 드리지만, 잘못된 것은 바로바로 연락을 주시면 곧 수정을 하도록 하겠습니다.
이 글에삽입된 클래스 다이어그램은 “Plastic Software”의 UML 모델링 툴인 “PLASTIC 2.0”을 이용하여그렸다.
oonewsletter - 2000/2/29