디자인 패턴 - 2

디자인 패턴 2

디자인 패턴은 23개나 되어 조직화하였다. 패턴을 분류하는 데 2가지 기준을 사용한다.

하나는 목적에 해당하는 기준으로 패턴이 무엇을 하지는지 정의하는 것이다. 패턴은 생성,구조, 행위 중의 한 가지 목적을 갖는다. 생성 패턴은 객체의 생성 과정에 관여하는 것이고 구조 패턴은 클래스나 객체의 합성에 관한 패턴들이다. 행위 패턴은 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의한다.

두 번째 분류 기준은 범위이다. 패턴을 주로 클래스에 적용하는지 아니면 객체에 적용하는지를 구분하는 것이다. 클래스 패턴은 클래스들과 서브클래스들 간의 관련성을 다루는 패턴이다. 관련성은 주로 상속이며 컴파일 시점에 정적으로 결정된다. 객체 패턴은 객체 관련성을 다루는 것으로 런타임 시에 동적으로 변경할 수 있다. 대부분의 패턴들은 어느 정도 상속을 이용한다. 클래스 패턴으로 정의한 패턴만이 클래스 관련성을 이용한다.

		목적
범위	생성	구조	행위
클래스	Factory Method	Adapter	Interpreter Template
			Template Method
객체	Abstract Factory	Adapter	Chain of Responsibility
	Builder	Bridge	Command
	Prototype	Composite	Iterator
	Singleton	Decorator	Mediator
		Facde	Memento
		Proxy	Flyweight
			Observer
			State
			Stategy
			Visitor

생성 클래스 패턴은 객체를 생성하는 책임의 일부를 서브클래스가 담당하도록 한다. 그러나 생성 객체 패턴은 이를 다른 객체에게 위임한다. 구조 클래스 패턴은 상속을 이용해서 클래스를 합성하고, 구조 객체 패턴은 객체를 합성하는 방법을 정의하고 있다. 행위 클래스 패턴은 상속을 이용해서 알고리즘과 제어 흐름을 기술하고, 행위 객체 패턴은 하나의 작업을 수행하기 위해 객체 집합이 어떻게 협력하는지를 기술한다.

패턴을 조직하는 다른 방법도 있다. 일부 패턴은 함께 사용해야 하는 경우도 있는데, 예를 들면 Composite 패턴은 Iterator 패턴과 Visitor 패턴과 함께 사용해야 하는 경우가 대부분이다. 또 어떤 패턴은 다른 패턴의 대안이 될 수 있다. Prototype 패턴은 Abstract Factory 패턴의 대안 패턴이다. 또 패턴들 간의 의도는 서로 다르지만, 결과적으로는 유사한 설계 구조를 만다는 패턴도 있다. Composite 패턴과 Decorator 패턴의 의도는 다르지만 구조는 매우 비슷하다.

디자인 패턴을 조직할 수 있는 방법은 다양하다. 패턴을 다양한 각도로 생각해 보는 것은 패턴이 무엇을 하고, 패턴들을 어떻게 비교할 것이며, 언제 적용할 것인가에 대한 우리들의 인식을 강화시켜 줄 것이다.

디자인 패턴을 이용하여 문제를 푸는 방법

디자인 패턴은 객체지향 설계자들이 매일 부딪히게 되는 많은 문제를 다양한 방법으로 해결해준다. 여기서 이들 문제 중 일부를 제시하고 디자인 패턴이 이 문제들을 어떻게 해결하는지 알아보자.

적당한 객체 찾기

객체지향 프로그램은 객체로 만들어진다. 객체는 데이터와 이 데이터를 처리하는 프로시저를 함께 묶은 단위이다. 프로시저를 일반적으로 메소드 또는 오퍼레이션이라고 부른다. 객체는 요청 또는 메시지를 클라이언트로부터 받으면서 오퍼레이션을 수행한다.

요청은 객체로 하여금 오퍼레이션을 실행하게 하는 유일한 방법이고 오퍼레이션은 객체의 내부 데이터의 상태를 변경하는 유일한 방법이다. 이러한 접근의 제약 사항으로 객체의 내부 상태는 캡슐화된다고 말한다. 객체 외부에서는 객체의 내부 데이터에 직접 접근할 수 없고, 객체의 내부 데이터 표현 방법을 알 수 없다.

객체지향 설계의 가장 어려운 부분은 시스템을 구설할 객체의 분할을 결정하는 것이다. 여러 요인을 고려해야 하기 때문에 매우 어려운 작업이다. 고려해야 할 요인이란 캡슐화, 크기 정하기, 종속성, 유연성, 성능, 진화, 재사용성 등을 의미한다. 이 모두를 어떻게 고려하는가에 따라서 서로 다른 방법으로 분할이 가능하다.

이 문제에 대해 객체지향 설계 방법론들을 서로 다른 접근법을 취하고 있다. 문제 기술서를 작성하고 명사와 동사를 추출해서 각각을 클래스와 오퍼레이션으로 만드는 방법도 있다. 시스템의 협력 관계나 책임성을 중심으로 설계를 하는 방법도 있고, 실세계를 모델로 만들고 이를 분석해 설계로 전이하는 과정에서 객체로 바꾸는 방법을 사용할 수도 있다. 그러나 어느 방법이 가장 돟은 방법이다라고는 말할 수 없다.

설계 단계의 객체들 대부분은 분석 모델에서부터 만들어진 것이다. 그러나 객체지향 설계는 실세계와 대응 관계를 갖지 못할 때가 많다. 즉, 분석 모델의 객체는 실세계 객체들이지만, 설계 모델의 객체는 배열, 리스트와 같은 구현에 가까운 클래스들도 존재한다. 어떤 설계 클래스들은 높은 수준의 추상화를 보일 수도 있는데, 예를 들어 Composite 패턴은 분석 모델과 물리적 대응 관계를 갖지는 않지만, 객체들을 동일하게 다루게 해주는 새로운 추상화 개념이다. 실세계를 그대로 반영하는 모델링만을 강조한다면 현재의 실세계는 반영할 수 있지만 미래의 실세계는 반영할 수 없다. 설계 단계 동안 만들어 내야 하는 새로운 추상화는 설계의 유연성을 증진하기 위한 중요한 노력 중 하나이다.

디자인 패턴은 모호한 추상화 개념을 찾아서 이를 객체로 만들어 준다. 처음 객체지향 프로그래밍을 하는 개발자들에게 프로세스나 알고리즘을 객체로 만드는 것은 자연스러운 일이 아니다. 그러나 프로세스나 알고리즘을 객체로 만드는 것은 유연한 설계를 만드는 데 필수적인 일이다.

Strategy 패턴은 상호 교환이 가능한 알고리즘군을 어떻게 구현할지를 설명하고 있다. State 패턴은 대상들의 각 상태를 객체로 만들었다. 이들 상태 객체들은 분석 단계에서는 거의 식별하기 어려운 것이고 설계의 초기 단계에서조차 어려운 일이다. 그러나 상태 객체, 알고리즘 객체 등은 설계를 좀더 유연하고 재사용한 것으로 만들려는 별도의 과정을 통해서나 발견할 수 있다.

객체의 크기에 대한 결정

객체는 크기와 수에서 매우 다양함을 보일 수 있다.

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

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