[월:] 2015년 08월

Design Patter 은 프로그래밍 코드의 모음이 아니다. 굳이 풀어보자면 UML 중 Class Diagram 에 가장 가까운 형태라고 보는게 표현식을 설명하는 좋은 방법일 것이다. 그렇다고 Design Pattern 이 Class Diagram 과 완전히 같다는 의미는 아니다. Design Pattern 은 프로그래밍 언어구조와 Sudo code(의사코드)의 관계와 비슷할것이다. 왜냐하면 Design Pattern 은 특정언어에 종속되지 않는 범용성을 가지는것이 기본이기 때문이다(물론 실제 코드를 구현하는 언어에 따라 다소의 차이는 있겠지만)

GoF 에 따르면 Pattern 은 Creation(생성), Structual(구조), Behavioral(행동) 의 세가지중 하나의 분류를 가진다고 얘기하고 있다. 그리고 이 목적별 특성은 Pattern 은 분류하는데 매우 유용하게 사용된다.

Design Pattern 에서 설명되는 Diagram 들은 UML 이 표준이 되기 전의 OMT 표기법을 기준하고 있기 때문에 UML 과 다소의 차이는 있곘지만 논리적으로 이해가 가지 않을 만큼의 차이점이 있지는 않으니 크게 문제는 없을것이라 예상한다.

Disign Pattern 은 보다 세련된 문제풀이를 위해 존재한다. 반드시 당신의 프로그램이 이러한 패턴을 사용해야 하는것은 아니지만, Design Pattern 을 이용하면 당신의 프로그램을 적은 노력으로 보다 세련되게 바꿀 수 있을것이다(물론 배우기 위한 노력이 들어가는것은 어쩔 수 없지만)

대부분의 Design Pattern 의 설명에는 동기(Motivation)가 같이 명기되어 있다. 이런 내용들을 먼저 한번 읽어보고 당신이 만들게될 프로그램에 적용할 수 있는 방법이 있는지를 생각해 보는것도 좋을것이다. 또는 패턴의 이름을 기억해두고 사전에서 꺼내쓰듯 사용하는 것도 좋은 방법이 될것이다. 하지만 제일 좋은 방법은 따로 있다. “백문이 불여일타”. 시험삼아서 당신이 할 수 있는 방법으로 시나리오를 만들고, 코드로 직접 구현해본다음, 이렇게 만들어진 것들을 Library 로 만들어서 필요할때 쓸 수 있도록 체화하는게 가장 좋은 방법이 아닐까?

Design Pattern 은 원래 Computer Science 에서 등장한 말이 아니다. 사실 Design Pattern 은 건축학자인 Christopher Alexander 의 다년간의 실험에 의한 결과로 등장한 이론이다. Alexander 는 그의 도시-건축-시공 에 대한, 도시의 발전과 개발계획에 대한 컨설팅 및 실험의 결과에서 도시의 발전은 그 형태의 필요에 따라 분류할 수 있는 형태가 존재한다는 것을 알았으며 이것을 표현하는 방법을 Pattern Language 라고 부르기 시작했다.

Erich Gamma 를 포함한 4명의 연구자들은 이 부분에 흥미를 느끼기 시작헀다. 사실 Alexander 의 실험은 결국 실패로 끝나고 학문적 성과로만 남는 결과가 되었지만, Design Pattern 은 전혀 생각지도 못한 분야에서 주목받게 되었다. 바로 Computer Science 라는 분야가 그것이다.

Xerox 의 Palo Alto 연구소에서 시작된 Object-Orientation Programming(객체지향 프로그래밍)과 Smalltalk 의 세계는 Personal Computer 의 물리적 성능의 한계때문에 이미 만들어졌음에도 불구하고 한동안 빛을 보지 못했다. Smalltalk 는 Star/Alto 머신 외의 일반 PC 에서 사용되기에는 너무 무거웠으며 C++ 는 C 언어에 비해서 Compile 속도가 너무 느렸다. 그러나 무어의 법칙대로 PC 의 성능은 비약적으로 발전했으며 소프트웨어 개발의 패러다임또한 변하기 시작헀다.

개발의 목표에 대해 기존에는 결과물의 성능이 최우선이었지만, 보다 개발의 편리성과 효율성이 중요해지기 시작했다. 기존의 Library 로 대표되던 Framework 은 재사용성과 프로그램 작업의 표율성을 위한 방향으로 만들어지기 시작했다. 기존의 Procedural(절차적) 프로그래밍 언어로는 한계가 오게 된것이다. 성능을 위해서만 발전한 언어의 Specification(명세) 만으로는 이러한 요구를 감당하기에는 역부족이었다. 이제 객체지향 프로그래밍 언어의 시대가 필요해지기 시작헀다.

객체지행 프로그래밍이 본격적으로 요구되게된 배경에는 프로그래밍 작업에 대하니 효율이 가장 컸다. Design Pattern(GoF) 이 사람들에게 다시 관심받게 된것은 어찌보면 당연한 순서일수도 있다. Design Pattern 의 목적 자체가 발견된 Pattern 을 통한 소프트웨어 개발에 도움이 되는 재사용성/업무의효율 에 있기 때문에 객체지향을 도입하는 목표와 Design Pattern 의 도입은 정확하게 일치한다고 봐아한다.