디자인 패턴 - 1

디자인 패턴

“디자인 패턴은 기존 환경 내에서 반복적으로 일어나는 문제들을 설명하고, 그 문제들에 대한 해법의 핵심을 설명하는 것이다. 이렇게 하면 똑같은 방법을 두 번 반복하지 않은 채 이 해법을 백만 번 이상 재사용할 수 있다.” 라는 말을 크리스토퍼 알렉산더라는 건축가가 이야기 하였다. 이것은 건축 디자인 뿐만 아니라 객체지향 설계에도 똑같이 적용된다.

보통 패텀은 다음 네 가지의 요소를 정의한다.

1. 패턴 이름은 힌두 단어로 설계 문제와 해법을 서술한다. 패턴에 이름을 부여하는 것은 설계 어휘를 늘리는 일이며 높은 수준의 추상화된 설계를 할 수 있도록 해준다. 패턴의 이름을 정의해 두면 문서에서 이 이름을 사용하여 설계의 의도를 표현할 수 있게 된다. 또 이렇게 이름을 갖게 되면 설계에 대한 생각을 더욱 쉽게 할 수 있고 개발자들 간의 의사소통이 원활하게 된다. 때문에 좋은 이름을 생각해 내는 것이 카탈로그를 성정하는 데 있어서 가장 힘든 부분 중의 하나이기도 한다.

2. 문제는 언제 패턴을 사용하는가를 서술하며 해결할 문제와 그 배경을 설명한다. 즉, “어떤 알고리즘을 객체로 만들까”와 같은 설계의 세밀한 문제를 설명할 수 있다. 때론 유연성 없는 설계가 될 징조를 보이는 클래스 구조나 객체의 구조를 제시한다. 문제를 제시함으로써 패턴을 적용하는 것이 의미 있는 경우들을 정의하기도 한다.

3. 해법은 설계를 구성하는 요소들과 드 요소들 간의 관계, 책임 그리고 협력 관계를 서술한다. 그렇다고 해법이 어떤 구체적인 설계나 구현을 설명하지는 않는다. 왜냐하면 패턴은 많은 다양한 경우에 적용할 수 있는 템플릿이기 때문에 어떤 특정 구현을 의미하지 않기 때문이다. 디자인 패턴은 문제에 대한 추상적인 설명을 제공하고 문제를 해결하기 위해서 클래스나 객체들의 나열 방법을 제공한다.

4. 결과는 디자인 패턴을 적용해서 얻는 결과와 장단점을 서술한다. 설계를 결정할 때 설계의 결과를 고려하지 않기가 쉬운데, 어떻게 보면, 선택하는 과정에서 또는 비용과 효과를 측정하는 과정에서 설계의 결과는 가장 중요한 부분이다. 소프트웨어에 있어서 결과란 가끔 시간이나 공간 사이의 균형일 수도 있다. 즉, 시간을 중요한 요소로 볼 것인지 아니면 저장 공간의 효율을 중요한 요소로 볼 것인지에 따라 다른 설계 방법을 선택해야 한다는 것이다. 또한 언어에 따라서도 차이가 있다. 재사용은 객체지향 설계의 주요 요소이므로, 패턴의 결과는 시스템의 유연성, 확장성, 이식성 등에 대한한 영향을 준다. 그래서 이런 설계의 결과들을 잘 정리하는 것은 나중에 패턴들을 이해하거나 평가하는 데 도움이 된다.

패턴에 대한 시각은 어떤 것이 패턴이고 어떤 것이 아닌가를 분석하는 데 영향을 준다. 어떤 사람에게는 패턴인 것이 다른 사람에게는 기본적인 빌딩 블록일 수도 있다. 이 책에서 우니는 어느 정도 수준의 추상화를 갖는 패턴에 전념하였다. 디자인 패턴은 클래스로 코딩되는 연결 리스트와 해시 테이블에 관한 설계를 패턴화하는 것이 아니다. 그렇다고 애플리케이션 전체나 서브시스템을 지원하는 복잡한 설계에 대한 패턴도 아니다. 이 책에서의 디자인 패턴은 “특정한 상황에서 일반적 설계 문제를 해결하기 위해 상호 교류하는 수정 가능한 객체와 클래스들”에 대한 설명이다.

디자인 패턴은 재사용 가능한 객체지향 설계를 만들기 위해 유용한 공통의 설계 구조로 부터 중요 요소들을 식별하여 이들에게 적당한 이름을 주고 추상화한 것이다. 디자인 패턴은 패턴에 찬여하는 클래스와 그들의 인스턴스를 식별하여 역할을 정의하고 그들 간의 협력 관계를 정의하고 책임을 할당한다. 각 디자인 패턴은 특정 객체지향 설계 문제에 집중하고 있다. 디자인 패턴은 언제 패턴을 적용할지, 다른 설계 제약을 고려하여 패턴을 적용할 수 있는지, 패턴을 사용했을 때의 결과가 어떻게 되는지를 기술한다. 또한, 우리는 궁극적으로는 설계를 구현해야 하기 때문에, C++ 또는 스몰토크 예제를 제공한다.

스몰토크 MVC를 사용한 디자인 패턴

스몰토크에서는 사용자 인터페이스를 만드는 데 MVC의 3가지 클래스를 사용하곤 한다. MVC가 갖는 디자인 패턴을 살펴보면 여러분이 “패턴”이라는 말의 의미를 이해하는 데 도움이 될 것이다.

MVC는 세 가지 객체로 이루어진다. 모델(Model)은 어플리케이션 객체이고, 뷰(View)는 스크린에 모델을 디스플레이하는 방법이며, 컨트롤러(Controller)는 사용자 인터페이스가 사용자 인터페이스가 사용자 입력에 반응하는 방법을 정의한다. MVC를 사용하기 전에는 사용자 인터페이스 설계가 이러한 객체들을 모두 묶어서 하나의 객체로 처리하였다. 유연성과 재사용성의 증대를 위해서 MVC는 이들 같의 결합도를 없앤다.

MVC는 뷰와 모델 간에 구독 신청/통보 프로토콜을 만들어 종속성을 없앤다. 뷰는 그 외형이 반드시 모델의 상태를 반영하도록 보장해야 한다. 모델의 데이터가 변경될 때마다 모델은 자신과 관련된 뷰에 알려 주고, 이 통보에 따라서 각 뷰는 스스로 자신의 외형을 변경해야 한다. 이 방법을 통해서 하나의 모델에 여러 뷰를 첨부하면 한 가지 모델에 대해서 여러 프레젠테이션을 지원할 수 있다. 또한, 모델을 수정할 필요가 없이 모델에 대해서 새로운 뷰들을 생성할 수도 있다.

한 객체에서의 변경을 다른 객체들에 반영하도록 별도의 객체를 두면 변경이 일어난 객체는 반영이 필요한 다른 객체들을 알 필요가 없다. 이런 설계를 일반화한 것이 Observer 패턴이다.

MVC의 다른 특징으로는 뷰를 중첩시킬 수 있다는 것이다. 예를 들어, 버튼의 제어 판텔은 여러 개의 버튼을 포함하는 복잡한 뷰로 구현할 수 있다. MVC는 Composite-View 클래스를 이용하여 중첩된 뷰를 지원하고, 또한 Composite View 객체를 View 객체처럼 다룰 수 있다. 즉, 복합 뷰 객체는 일반 뷰 객체가 사용되는 곳이면 동일하게 사용될 수 있다.

이는 복합 뷰를 마치 하나의 단일 뷰와 동일한 것처럼 사용하려는 설계 개념이다. 이 설계 역시 일반적인 문제에 적용이 가능하다. 일반적으로 단일 객체처럼 복합 객체를 사용하고 싶은 때가 많은데 이런 일반적 설계를 담고 있는 것이 Composite 패턴이다.

MVC는 시작적 표현 방법의 변경 없이 사용자 입력에 대한 뷰의 반응 방법을 변경할 수 있다. 명령 키 대신 팝업 메뉴를 사용할 수도 있고 키보드를 이용하도록 변경할 수도 있다. MVC에서는 Controller 객체를 이용하여 반응 방법을 캡슐화한다. 컨트롤러의 클래스 계층을 통해서 기존의 방식과 다른 방식을 새로운 컨트롤러로 정의하게 하는 것이다.

특정 대응 전략을 구현하기 위해 View 클래스가 Controller 서브클래스의 인스턴스를 사용한다면, 다른 전략을 구현하기 위해 현재의 컨트롤러 인스턴스를 다른 종류의 컨트롤러의 인스턴스로 대체만 하면 된다. 이런 방식을 이용하면 사용자 입력에 대응하는 뷰의 방식을 변경하는 것이 런타임 시에도 가능하다. 뷰가 제거되어 입력을 수용하지 못하도록 해야 할 경우라면, 사용자 이벤트를 무시하는 컨트롤러를 제공하면 된다.

뷰와 컨트롤러 관계는 Strategy 패턴의 한 예이다. Strategy 패턴은 알고리즘을 표현하는 객체로 정적 또는 동적으로 알고리즘을 대체하고자 할 때 매우 유용한 방식이다. 또한 다양한 알고리즘의 변형이 가능할 때, 알고리즘이 캡슐화해야 할 데이터 구조가 복잡한 경우 유용한 방식이기도 하다.

MVC는 Factoty Method 패턴을 이용해서 뷰에 대한 기본 컨트롤러 클래스를 명세할 수도 있고, Decorator 패턴을 이용해서 뷰에 스크롤을 추가할 수도 있다. 그러나 MVC의 주요 기능을 처리하는 데 가장 중요한 패턴들은 Observer, Composite,Strategy 패턴이다.

디자인 패턴 기술하기

어떻게 디자인 패턴을 서술할까? 그래픽 표현은 중요하고 유용하지만 디자인 패턴을 서술하기에는 충분하지 않다. 이런 다이어그램들은 설계 공정의 마지막 산출물로 클래스와 객체들 간의 관련성을 표현할 뿐이다. 설계를 재사용하기 위해서는 설계를 하기까지의 다양한 결정, 대안, 장단점 등을 고려한 과정을 기록해야 한다.

이 책에서는 일정한 형태를 이용해서 디자인 패턴을 서술해 놓았다. 각각의 패턴은 다흠의 템플릿에 따라서 구분하여 정의하였다. 템플릿은 디자인 패턴을 배우고 비교하고 사용하기 더 쉽도록 하기 위해 일관된 구조를 제공한다.

패턴 이름과 분류

패턴의 이름은 핵심을 간결하게 전달해 주어야 한다. 설계의 어휘로 이용되기 때문에, 좋은 이름은 패턴의 생명이다.

• 의도(Intent)

  디자인 패턴은 다음 질문에 간결한 답을 함으로써 의도를 표현한다. 디자인 패턴은 무엇을 하는 것이가? 의도와 논리적인 근거가 무엇인가? 어떤 특정한 문제나 이슈를 해결하기 위한 것인가?

• 다른 이름(Also Known As)

  패턴을 다른 이름으로도 정의할 수 있다면, 그것은 무엇인가?

• 동기(Motivation)

  동기는 설계 문제를 제시하고, 패턴 안에서 클래스나 객체 구조가 어떻게 문제를 해결하는지 설명해 주는 일종의 시나리오이다. 이 시나리오는 패턴에 대한 좀더 추상화된 설명을 이해할 수 있게 도와준다.

• 활용성(Applicability)

  디자인 패턴을 어떤 상황에 적용할 수 있는가? 패턴이 문제로 삼는 잘못된 설계의 예는 무엇인가? 이 상황을 어떻게 파악할 우 있는가?

• 구조(Structure)

  Object Modeling Techniques 표기법을 이용해 패턴에서 정의할 클래스를 모델링한다. 요청과 객체들 간의 협력 관계의 순서를 표현하기 위해서 상호작용 다이어그램을 이용하였다.

• 참여 객체(Participants)

  패턴을 구성하고 책임을 수행하는 클래스나 객체들

• 협력 방법(Collaborations)

  참여 객체들이 작업을 수행하기 위해서 어떻게 협력하는지의 관계를 정의한다.

• 결과(Consequences)

  패턴이 목표를 어떻게 지원하는가? 패턴을 이용한 결과는 무엇이고 장단점은 무엇인가? 시스템의 어떤 부분을 독립적으로 다양화할 수 있게 하는가?

• 구현(Implementation)

  패턴을 구현할 때 주의해야 할 함정, 힌트, 기법 등은 무엇인가? 특정 언어에 국한된 특이 사항은 무엇인가?

• 예제 코드(Sample Code)

  실제로 C++나 스몰토크를 이용해서 패턴을 어떻게 구현할 수 있는가를 보여 주는 코드이다.

• 잘 알려진 사용예(Known Uses)

  실제 시스템에서 볼 수 있는 패턴들의 예로 서로 다른 영역으로부터 두 가지 이상의 예제를 제공한다.

• 관련 패턴(Related Patterns)

  이 패턴과 관련된 다른 패턴들이 무엇인가? 중요한 차이점들은 무엇인가? 어떤 다른 패턴에 이 패턴이 사용될 수 있는가?

디자인 패턴 종류

• Abstract Factory

  구체적인 클래스를 지정하지 않고 관련성을 갖는 객체들의 집합을 생성하거나 서로 독립적인 객체들의 집합을 생성할 수 있는 인터페이스를 제공한다.

• Adapter

  클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환한다. Adapter 패턴은 호환성이 없는 인터페이스 때문에 함께 사용할 수 없는 클래스를 개조하여 함께 작독하도록 해준다.

• Bridge

  추상화와 구현을 분리하여 각각을 독립적으로 변형할 수 있게 한다.

• Builer

  복합 객체의 생성 과정과 표현 방법을 분리함으로써 동일한 생성 공정이 서로 다른 표현을 만들 수 있게 한다.

• Chain of Responsibility

  요청을 처리할 수 있는 기회를 하나 이상의 객체에게 부여함으로써 요청하는 객체와 처리하는 객체 사이의 결합도를 없애려는 것이다. 요청을 해결할 객체를 만날 때까지 객체 고리를 따라서 요청을 전달한다.

• Command

  요청을 객체로 캡슐화함으로써 서로 다른 요청으로 클라이언트를 파라미터화하고, 요청을 저장하거나 기록을 남겨서 오퍼레이션의 취소도 가능하게 한다.

• Composite

  부분-전체 계층을 나타내기 위해 복합 객체를 트리 구조로 만든다. Composite 패턴은 클라이언트가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다.

• Decorator

  객체에 동적으로 책임을 추가할 수 있게 한다. Decorator 패턴은 기능의 유연한 확장을 위해 상속 대신 사용할 수 있는 방법이다.

• Facade

  서브시스템에 있는 인터페이스 집합에 대해서 하나의 통합된 인터헤이스를 제공한다. Facade 패턴은 서브시스템을 좀더 사용하기 편하게 하기 위해서 높은 수준의 인터페이스를 정의한다.

• Factory Method

  객체를 생성하는 인터페이스를 정의하지만, 인스턴스를 만들 클래스의 결정은 서브클래스가 한다. Factory Method 패턴에서는 클래스의 인스턴스를 만드는 시점을 서브클래스로 미룬다.

• Flyweight

  작은 크기의 객체들이 여러 개 있는 경우, 객체를 효과적으로 사용하는 방법으로 객체를 공유하게 한다.

• Interpreter

  언어에 따라서 문법에 대한 표현을 정의한다. 또한 언어의 문장을 해석하기 위해 정의한 표현에 기반하여 분석기를 정의한다.

• Iterator

  내부 표현 방법을 노출하지 않고 복합 객체의 원소를 순차적으로 접근 할 수 있게 방법을 제공한다.

• Mediator

  객체들 간의 상호작용을 객체로 캡슐화한다. Mediator 패턴은 객체등 간의 참조 관계를 객체에서 분리함으로써 상호작용만을 독립적으로 다양하게 확대할 수 있다.

• Memento

  캡슐화를 위배하지 않고 객체 내부 상태를 객체화하여, 나중에 객체가 이 상태로 복구 가능하게 한다.

• Observer

  객체 사이에 일 대 다의 종속성을 정의하고 한 객체의 상태가 변하면 종속된 다른 객체에 통보되고 자동으로 수정이 일어나게 한다.

• Prototype

  프로토타입의 인스턴스를 이용해서 생성할 객체의 종류를 명세하고 이 프로토타입을 복사하여 새로운 객체를 생성한다.

• Proxy

  다른 객체오릐 접근을 통제하기 위해서 다른 객체의 대리자 또는 다른 객체로의 정보 보유자를 제공한다.

• Singleton

  클래스의 인스턴스는 오직 하나임을 보장하며 이 인스턴스에 접근할 수 있는 방법을 제공한다.

• State

  객체의 내부 상태에 따라 행위를 변경할 수 있게 한다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.

• Strategy

  알고리즘군이 존재할 경우 각각의 알고리즘을 별도의 클래스로 캡슐화하고 이들을 상호 교환 가능한 것으로 정의한다. Strategy 패턴은 클라이언트에 영향을 주지 않고 독립적으로 알고리즘을 다양하게 변경할 수 있게 한다.

• Template Method

  오퍼레이션에는 알고리즘의 처리 과정만을 정의하고 각 단계에서 수행할 구체적 처리는 서브클래스에 정의한다. Template Method 패턴은 알고리즘의 처리 과정은 변경하지 않고 알고리즘 각 단계의 처리를 서브클래스에서 재정의할 수 있게 한다.

• Visitor

  객체 구조의 요소들에 수행할 오퍼레이션을 표현할 패턴이다. Visitor 패턴은 오퍼레이션이 처리할 요소의 클래스를 변경하지 않고도 새로운 오퍼레이션을 정의할 수 있게 한다.

이 포스팅은 GOF의 디자인 패턴 내용의 일부를 작성하였습니다.

Erich Gramma, Richard Helm, Palph Johnson, John Vlissides 공저 (김정아 역)