건축가이자 패턴의 아버지, 크리스토퍼 알렉산더는 "각 디자인 패턴은 기존 환경내에서 반복적으로 일어나는 문제들을 설명한 후, 그 문제들에 대한 해법의 핵심을 설명해 준다. 똑같은 방법으로 두 번 하지 않고 이 해법을 100만 번 이상 재사용할 수 있도록 해준다."라고 하였다. 알렉산더가 말한 것은 물론 시가지나 빌딩에 대한 이야기이긴 하지만, 객체지향 설계에도 해당된다.
소프트웨어 개발에서 해법은 벽이나 문들 대신에 객체와 인터페이스를 사용하지만, 둘 모두 패턴을 "어떤 상황의 문제에 대한 해법"으로 본다는 공통점이 있다.
일반적으로 하나의 패턴에는 다음의 네 가지 요소가 반드시 포함되어 있다.
1. 패턴 이름(pattern name)은 한 두 단어로 설계 문제와 해법을 서술한다. 패턴에 이름을 부여하는 것은 설계 어휘를 늘리는 일이며, 높은 수준의 추상화된 설계를 할 수 있도록 해 준다. 패턴의 이름을 정의해 두면 문서에서 이 이름을 사용하여 설계의 의도를 표현할 수 있게 된다. 또 이렇게 이름을 갖게 되면 설계에 대한 생각을 더욱 쉽게 할 수 있고, 개발자들 간의 의사소통이 원활해진다. 이 때문에 좋은 이름을 생각해 내는 것은 카탈로그를 설정하는데 있어서 가장 힘든 부분 중의 하나이기도 하다.
2. 문제(problem)는 언제 패턴을 사용하는가를 서술하며 해결할 문제와 그 배경을 설명한다. 즉, "어떤 알고리즘을 객체로 만들까?" 와 같은 설계의 세밀한 문제를 설명할 수 있다. 때론 유연성 없는 설계가 될 징조를 보이는 클래스나 객체의 구조를 제시한다. 문제를 제시함으로써 패턴을 적용하는 것이 의미 있는 사례들을 정의하기도 한다.
3. 해법(solution)은 설계를 구성하는 요소들과 그 요소들 간의 관계, 책임 그리고 협력 관계를 서술한다. 그렇다고 해법이 어떤 구체적인 설계나 구현을 설명하지는 않는다. 왜냐하면 패턴은 다양한 경우에 적용할 수 있는 템플릿(template)이기 때문이다. 구체적인 부분 대신, 디자인 패턴은 문제에 대한 추상적인 설명을 제공하고 문제를 해결하기 위해서 클래스나 객체들의 나열 방법을 제공한다.
4. 결과(consequence)는 디자인 패턴을 적용해ㅓ 얻는 결과와 장단점을 서술한다. 어떤 설계를 결정할 때 그 설계의 결과를 고려하지 않기가 쉬운데, 어떻게 보면, 선택하는 과정에서 또는 비용과 효과를 측정하는 과정에서 설계의 결과는 가장 중요한 부분이다. 소프트웨어서 결과란 가끔 시간이나 공간 사이의 균형일 수 잇다. 즉, 시간을 중요한 요소로 볼 것인지 아니면 저장 공간의 효율을 중요한 요소로 볼 것인지에 따라 다른 설계 방법을 선택해야 한다는 것이다. 또한 언어에 따라서도 차이가 있다. 재사용은 객체지향 설계의 주된 요소이므로, 패턴의 결과는 시스템의 유연성, 확장성, 이식성 등에 커다란 영향을 준다. 그래서 이런 설계의 결과들을 잘 정리해 두면 나중에 패턴들을 이해하거나 평가하는 데 도움을 받을 수 있다.
패턴에 대한 시각은 패턴을 구분하고 분석하는 데 영향을 준다. 어떤 사람에게는 그것이 패턴이지만 다른 사람에게는 지극히 기초적인 조립용 부품으로 보일 수도 있다. 디자인 패턴은 연결 리스트와 해시 테이블 등을 클래스로 표현하고 그것 자체로 다시 쓸 수 있도록 설계하는 문제를 어떻게 푸느냐에 관한 것이 아니다. 응용 프로그램 전체나 서브시스템을 지원하는 복잡한 설계에 대한 것은 더더욱 아니다. 여기서 얘기하는 디자인 패턴은 "특정한 전후 관계에서 일반적 설계 문제를 해결하기 위해 상호교류하는 수정 가능한 객체와 클래스들에 대한 설명"이다.
하나의 디자인 패턴은 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조에서 주요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화한다. 그리고 패턴에 참여하는 클래스와 그들의 인스턴스를 식별하여 역할과 그들 간의 협력 관계를 정의하고 책임을 할당한다.
소프트웨어 개발에서 해법은 벽이나 문들 대신에 객체와 인터페이스를 사용하지만, 둘 모두 패턴을 "어떤 상황의 문제에 대한 해법"으로 본다는 공통점이 있다.
일반적으로 하나의 패턴에는 다음의 네 가지 요소가 반드시 포함되어 있다.
1. 패턴 이름(pattern name)은 한 두 단어로 설계 문제와 해법을 서술한다. 패턴에 이름을 부여하는 것은 설계 어휘를 늘리는 일이며, 높은 수준의 추상화된 설계를 할 수 있도록 해 준다. 패턴의 이름을 정의해 두면 문서에서 이 이름을 사용하여 설계의 의도를 표현할 수 있게 된다. 또 이렇게 이름을 갖게 되면 설계에 대한 생각을 더욱 쉽게 할 수 있고, 개발자들 간의 의사소통이 원활해진다. 이 때문에 좋은 이름을 생각해 내는 것은 카탈로그를 설정하는데 있어서 가장 힘든 부분 중의 하나이기도 하다.
2. 문제(problem)는 언제 패턴을 사용하는가를 서술하며 해결할 문제와 그 배경을 설명한다. 즉, "어떤 알고리즘을 객체로 만들까?" 와 같은 설계의 세밀한 문제를 설명할 수 있다. 때론 유연성 없는 설계가 될 징조를 보이는 클래스나 객체의 구조를 제시한다. 문제를 제시함으로써 패턴을 적용하는 것이 의미 있는 사례들을 정의하기도 한다.
3. 해법(solution)은 설계를 구성하는 요소들과 그 요소들 간의 관계, 책임 그리고 협력 관계를 서술한다. 그렇다고 해법이 어떤 구체적인 설계나 구현을 설명하지는 않는다. 왜냐하면 패턴은 다양한 경우에 적용할 수 있는 템플릿(template)이기 때문이다. 구체적인 부분 대신, 디자인 패턴은 문제에 대한 추상적인 설명을 제공하고 문제를 해결하기 위해서 클래스나 객체들의 나열 방법을 제공한다.
4. 결과(consequence)는 디자인 패턴을 적용해ㅓ 얻는 결과와 장단점을 서술한다. 어떤 설계를 결정할 때 그 설계의 결과를 고려하지 않기가 쉬운데, 어떻게 보면, 선택하는 과정에서 또는 비용과 효과를 측정하는 과정에서 설계의 결과는 가장 중요한 부분이다. 소프트웨어서 결과란 가끔 시간이나 공간 사이의 균형일 수 잇다. 즉, 시간을 중요한 요소로 볼 것인지 아니면 저장 공간의 효율을 중요한 요소로 볼 것인지에 따라 다른 설계 방법을 선택해야 한다는 것이다. 또한 언어에 따라서도 차이가 있다. 재사용은 객체지향 설계의 주된 요소이므로, 패턴의 결과는 시스템의 유연성, 확장성, 이식성 등에 커다란 영향을 준다. 그래서 이런 설계의 결과들을 잘 정리해 두면 나중에 패턴들을 이해하거나 평가하는 데 도움을 받을 수 있다.
패턴에 대한 시각은 패턴을 구분하고 분석하는 데 영향을 준다. 어떤 사람에게는 그것이 패턴이지만 다른 사람에게는 지극히 기초적인 조립용 부품으로 보일 수도 있다. 디자인 패턴은 연결 리스트와 해시 테이블 등을 클래스로 표현하고 그것 자체로 다시 쓸 수 있도록 설계하는 문제를 어떻게 푸느냐에 관한 것이 아니다. 응용 프로그램 전체나 서브시스템을 지원하는 복잡한 설계에 대한 것은 더더욱 아니다. 여기서 얘기하는 디자인 패턴은 "특정한 전후 관계에서 일반적 설계 문제를 해결하기 위해 상호교류하는 수정 가능한 객체와 클래스들에 대한 설명"이다.
하나의 디자인 패턴은 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조에서 주요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화한다. 그리고 패턴에 참여하는 클래스와 그들의 인스턴스를 식별하여 역할과 그들 간의 협력 관계를 정의하고 책임을 할당한다.
