---

"눈 위의 발자국을 찾아서 그 위에다 인도를 만들기"
" Looking for footprint in the snow and putting the pavement there"
- Brian Foote[2] -

---

객체지향 패러다임(object-oriented paradigm)이 줄 수 있는 가장 큰 이점은 무엇일까? 그것은 아마도  다형성(polymorphism)을 통한 재사용성(reusablility)일 것이다. 새로운 프로그램을 만들려고 하는데 이미 이전에 내가 만들려고 하는 프로그램의 기능 일부에 대한 코드(code)가 만들어져 있다면, 이 얼마나 행복한 일인가? 객체지향 패러다임을 적용한 시스템 중에서 다형성을 가장 쉽게 느낄 수 있는 것이 객체지향 언어에서 제공하는 “상속(inheritance)”일 것이다. (이 글을 객체지향 패러다임에 대한 것이 아니므로 다형성에 대한 구체적인 설명과 예는 관련 서적을 참고) 

그러나, 이러한 다형성은 프로그램 언어에 있어서는 코드의 재사용, 그래픽 사용자 인터페이스(Graphic User Interface, GUI)에서는 메타포(metaphor)의 재사용, 분산 시스템(distributed system)에서는 인스턴스(instance)의 재사용 등의 다양한 재사용을 제공하지만, 정작 시스템 디자인 측면에서의 재사용성을 제공하는 구체적인 방법은 없는 것 같다. 하나의 시스템을 구축하는데 있어서 객체 지향 패러다임이 가지고 있는 다형성을 이용하지 않고 시스템 디자인 측면에서 재사용성을 얻을 수 있는 방법으로 “디자인 패턴(Design patterns)”이 있다. 이 글에서 앞으로 알아보려고 하는 디자인 패턴은 시스템 구축과정에서 코드 수준에서의 재사용성을 가능하게 해 주지는 않지만 그 보다 더 중요한 시스템 디자인시의 “디자인 재사용성”을 제공하여 준다. 

“디자인 재사용성”을 제공하는 디자인 패턴에 대한 중요성을 인식하고 객체지향 뉴스레터의 한 섹션으로 “디자인 패턴”에 대한 부분을 할애 하였다.   “디자인 패턴”을 들어 본 독자도 있을 것이고 그 이름이 생소하게 들리는 독자도 있을 것이다. 이 번에는 우선 그 첫번째로 디자인 패턴이 무엇인가에 대해서 알아보고 앞으로 어떻게 이야기를 전개해 나갈 지에 대해서 이야기한다.  본격적인 시작은 다음 호부터 하도록 할 예정이다. 
 
 

▶ 디자인 패턴이란?

여러 사람들이 말하는 디자인 패턴에 대한 정의를 종합해 보면 디자인 패턴이란 한 마디로 

이라고 정의할 수 있다. 위의 정의의 의미를 브라이언 후트(Brian Foote)[2]는 영악하고 게으른 건축가에 대한 재미있는 이야기를 통해서 잘 설명하고 있다. 

어는 한 건축가가 대학 건물과 그 주변의 인도에 대한 설계를 맞게 되었다. 그러나 그 건축가는 대학 건물만을 설계해 놓고 그 건물 주변의 인도에 대한 설계는 하지 않고 있었다. 그래서 건물은 지어졌지만 사람이 다닐 수 있는 인도는 아직 없었다. 시간이 지나서 눈이 내리는 겨울이 되었다. 사람들은 건물 주위에 인도가 없었기  때문에 각자가 편한 대로 건물주위를 걸어 다녔다. 겨울이 되기 전까지 인도를 만들지 않고 게으름(?)을 피우던 건축가는 사진기를 가지고 사람들이 눈 위에 만들어 놓은 건물과 건물 사이의 발자국의 모양을 찍기 시작했다. 긴 겨울이 지나고 봄이 되어서 건축가는 겨울 내 찍어 두었던 발자국의 사진을 바탕으로 인도를 만들기 시작했다. 디자인 패턴은 이와  같은 성질을 가지고 있다. 디자인 패턴 작가(writer)는 시스템이 어떻게 동작할 가에 대한 성급하고 검증되지 않은 추측을 바탕으로 시스템에 대한 설계를 하기 보다는 영악하고 게으른 건축가처럼 눈 위의 발자국을 찾아서 어떻게 작동했는지를 기술한다.

그러면 디자인 패턴이 주는 이점은 무엇일까? 크게 두 가지로 생각해 볼 수 있다. 경험이 많은 소프트웨어 엔지니어의 경우에는 이미 많은 시스템 디자인 경험을 가지고 있어서 대부분의 문제에 대한 나름대로의 해법을 가지고 있을 것이다. 경험이 많은 소프트웨어 엔지니어들의 이  같은 해법들을 잘 정리해서 이름을 부여하고 디자인적인 추상성을 주어 패턴화 시키면, 이 것들이 하나의 시스템 디자인 시의 공통 언어 역할을 하게 되어, 경험 많은 이들이 이 공통의 언어를 이용하면 그렇지 않을 경우보다 좀 더 효율적으로 협동 작업을 할 수 있게 된다. 또한 이것은 어떤 문제에 대해서 표현만 다르게 되어 있는 같은 해법에 대한 소프트 엔지니어들에 사이의 불필요한 논쟁을 하는 시간을 줄여줄 수 도 있다. 경험이 없는 소프트웨어 엔지니어에 대해서는 경험 많은 이들로부터의 효율적이고 유용성이 좋은 디자인에 대한 해법을 짧은 시간에 익히고 얻어 자신이 디자인 하고 있는 시스템의 안정성과 성능을 높일 수 있는 장점이 있다.
 
 

▶ 디자인 패턴의 역사

소프트웨어에 대한 디자인 패턴의 아이디어는 건축 분야에서 나왔다. 1977년과 1979년에 건축가인 크리스토퍼 알렉산더(Christopher Alexander)는 “A Pattern Language:Towns, Buildings, Construction”라는 제목의 책과 “The Timeless Way of Building”이라는 제목의 책 두 권을 발표했다.  이 두 권의 책이 담고 있는 기본 아이디어는 건축물의 설계에 빈번하게 발생하는 동일 설계 내용이 있으며 따라서, 이런 것들을 하나의 패턴으로 보고 다른 건축물 설계에 재사용하는 것이 여러 가지 면에서 이득을 가져 다 준다는 것이다.  두 권의 책이 담고 있는 이런 기본 아이디어는 건축 영역을 벗어난 소프트웨어와  같은 다른 영역에서도 적용할 수 있었다. 

1987년 워드 커닝험(Ward Cunningham)과 켄트 벡(Kent Beck)은 알렉산더의 아이디어를 사용해서 사용자 인터페이스(User interface)에 대한 다섯 가지의 패턴을 만들었다. 그리고 이 내용은 “Using Pattern Languages for Object-Oriented Programs”라는 제목으로 정리되어 객체 지향에 관한 세계적인 컨퍼런스(conference)인 OOPSLA-87(Object-Oriented Programming, Systems, Languages & Applications ? 87)에 논문으로 발표되어 디자인 패턴에 대해서 학계에 공식적으로 알리는 계기가 되었다. 

1990년대 초에는 에릭 감마(Erich Gamma), 리차드 헬름(Richard Helm), 존 블리자이드(John Vlissides), 랄프 존슨(Ralph Johnson)이 90년대 가장 영향을 주었던 컴퓨터 책의 한 가지인 “Design Patterns: Elements of Reusable Object-Oriented Software”이란 책 제작을 시작 했다. 이 책은 1994년에 발표되어 디자인 패턴에 대한 아이디어를 널리 알리는 계기를 만들었으며, 이 책은 책의 제목이 긴 이유로 인해서 'GoF(Gang of Four) book'라는 별칭으로 불리고 있다. 
 
 

▶ 앞으로의 이야기 전개…

현재 미국내의 패턴 컨퍼런스(conference)인 PloP(Pattern Languages of Programs)와 유럽의 패턴 컨퍼런스인 EuroPLoP를 통해서 공식적으로 발표되어 알려져 있는 디자인 패턴의 수는 수 백가지에 이른다.  이 모든 디자인 패턴에 대해서 모두 알아 본다는 것은 가능하지도 않고 필요하지도 않다.  왜 모든 디자인 패턴을 익히는 것이 필요하지 않은지는 앞으로 디자인 패턴을 하나씩 소개하면서 이야기할 것이다. 그리고, 그 것은 필자가 구지 이야기 하지 않아도 디자인 패턴을 익혀 가면서 자연스럽게 알게 될 것이라 생각이 든다. 

따라서, 객체지향 뉴스레터의 디자인 패턴 섹션에서 다루려는 것은 가장 기본적이라고 인정되고 있는 Gang of Four[1]에 나와 있는 것들을 중심으로 디자인 패턴이 갖고 있는 의미를 생각해 볼 예정이다.

대부분의 것이 그렇듯이 공짜는 없다.  디자인 패턴도 우리가 기대하는 마법의 봉을 우리들의 손에 쥐어 주지는 않는다.  디자인 패턴도 어떤 의미에선 우리가 객체 지향적인 시스템을 디자인 하는데 있어서 유용하게 사용할 수 있는 하나의 도구로 볼 수 있다. 따라서, 우리가 디자인 패턴을 시스템 디자인 시에 효율적으로 사용하기 위해서는 꾸준한 공부와 배운 것을 적용해 보려는 노력이 필요하며 종국에 가서는 새로운 디자인 패턴을 찾아 내어 정리할 수 있는 능력도 길러야 할 것이다.

지금까지 디자인 패턴이 무엇인지를 간단히 설명하여 보았다. 하지만, 위의 몇 자 안 되는 글의 내용을 통해서는 디자인 패턴에 대한 감을 잡기 어려울 것이다. 아무리 수박 맛을 이야기 해 준들, 한 여름의 수박 맛을 보지 않고 어떻게 알 수 있겠는가?  다음 호에서는 위에서 이야기한 디자인 패턴에 대한 일반적인 이야기를 구체적인 패턴을 통해 확인해 볼 수 있을 것이다. 
 
 

▶ 이 글을 읽는 분들에게…

필자도 현재 디자인 패턴을 공부하며 공부한 것을 연구실에서 진행하고 있는 시스템에 적용해 보려는 노력과 현재 디자인 하고 있는 시스템에서 사용되어 지고 있는 패턴을 찾아보려는 시도를 하고 있습니다. 따라서, 아직 필자도 부족한 점이 많은 가운데에 이 글을 쓰고 있는 상황이라 글의 내용 가운데는 잘못된 점이 많이 있으리라 생각합니다. 글의 내용 가운데에 앞뒤가 맞지 않는 부분이나 잘못된 부분이 없도록 최대한 노력을 기울이겠지만, 혹시라도 그런 것들이 발견되면 서슴없이 알려 주기 바랍니다. 이 글은 저와 이 글을 읽는 여러분들이 함께 쓰는 것이라고 생각을 합니다.
 
 
 

▶ 코딩 규칙(Coding rules)
 

이 곳에서는 디자인 패턴에서 다음 호부터 사용할 자바언어의 코딩 규칙에 대해서 설명한다.  왜 자바 언어를 사용하는지는 다음 호의 글을 참조하라. 

개인적으로 사용하고 있었던 나름대로의 코딩 규칙도 있고, 연구실에서 팀 프로젝트를 하면서 따랐던 코딩 규칙도 있었지만, 여기서는 Doug Lea의 코딩 규칙을 따른다[3].  특별히 Doug Lea가 사용하고 있는 코딩규칙을 따르는 이유는 없다. Nigel Warren과 Philip Bishop이 쓴 책에서 Doug Lea의 코딩 규칙을 따라 자바 코드를 사용하고 있는데, 개인적으로 볼 때 Doug Lea의 코딩 규칙은 전체적으로 명확하여 코드의 의미전달이 잘 전달된다고 생각했기 때문이다[4]. 다음은 Doug Lea의 코딩 규칙으로 Nigel Warren과 Philip Bishop이 쓴 책에서 정리해 놓은 것을 적은 것이다.
 

Packages
    lowercase

Interface
    UpperAndLowerCase

Class 이름
    UpperAndLowerCase

또는 Interface와 구분 짓기 위해서 
    InterfaceNameImpl

Abstract class
    UpperAndLowerCase

또는 Interface와 구분 짓기 위해서
    AbstractInterfaceName

Exception class
    ClassNameEndsWithException
    ReallyLongClassNameEndsWithException

Constants
    UPPER_CASE_WITH_UNDERSCORES

Instance and class variables(fields)
    trailingUnderscore_

Local variables
    firstWordLowerCase

Methods
   firstWordLowerCase()
 

예)

public class CodingConventionsImpl 
            extends AbstractCodingConventions
            implements CodingConventions   {

     private int intField_;
     public static final int PUBLIC_CONSTANT = 0;

     public void mehodThatThrowsException()
              throws CodingConventionException  { . . . }

     public void methodWithLocalVariable(int[] array) {
             int numObjects = array.length;
     }
}
 
 
 

참고 문헌 

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 
       Design Patterns, Addison-Wesley, 1995.

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

[3] Doug Lea, Concurrent Programming in Java, Addison-Wesley , 1997

[4] Nigel Warren, Philip Bishop, Java in Practice, Design Styles and Idioms for 
       Effective Java, Addison-Wesley, 1999