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 로 만들어서 필요할때 쓸 수 있도록 체화하는게 가장 좋은 방법이 아닐까?