본문 바로가기
SW

GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.8~2.9)

by 라꾸스떼(YR) 2020. 4. 15.
반응형

[순회, 그리고 순회 중의 작동]

순회와 순회 중 작동을 따로 떼어놓을 수 있다면 훨씬 더 높은 유연성과 재사용성을 얻을 수 있다. 분석 방법마다 사용되는 순회 방법이 한 가지가 아니라 여러 가지이기 때문이다. 분석과 순회는 분리해야 한다.

분석 방법은 글리프의 종류를 구별할 수 있어야 한다. 쉽게 생각할 수 있는 한 가지 방법은 분석 기능을 Glyph 클래스 자체에 넣는 것이다. 이 방법의 문제는 새로운 분석이 추가될 때마다 모든 Glyph 클래스를 변경해야 한다는 것이다.

 

[분석 작업을 캡슐화하기]

분석 작업 자체를 별도의 객체로 캡슐화할 필요가 있다. 분석 작업을 나타내는 별도의 클래스를 정의하고, 이 클래스의 인스턴스를 반복자와 함께 사용한다. 반복자는 문서 구조를 이루는 원소들을 하나씩 순회하고, 반복자가 방문한 원소에 대해서 분석 객체가 분석을 처리한다. 이 방법을 쓰려면 근본적인 의문점 하나를 해결해야 한다. 분석 객체가 타입 검사와 다운캐스트 기능에 의존하지 않고 어떻게 글리프이 종류를 구분할 수 있을까 하는 것이다.

각 글리프를 만날 때마다 철자 검사기를 매개변수로 넘겨 CheckMe() 연산을 호출하면서 글리프 구조를 순회할 수 있게 되었다. 따라서 철자 검사를 적용할 각 글리프를 효과적으로 식별하고 다음 번 요소로 바로 진행할 수 있다.

하나의 인터페이스로 정의하면 서로 다른 알고리즘을 이용할 때 다형성의 특성도 얻을 수 있다. 즉, CheckMe(SpellingChecker&)연산과 같이 분석 의존형 연산 대신에 좀더 일반적인 매개변수를 받는 분석 독립적 연산으로 바꿀수 있다는 뜻이다.

 

[Visitor 클래스와 서브클래스]

구조를 순회하는 도중에 그 구조를 구성하는 다른 객체에 “방문(visit)”하여 적절한 일을 수행하는 객체의 클래스 : visitor(방문자)

구조 내의 글리프를 방문하는 추상 인터페이스를 가진 Visitor 클래스

각기 다른 분석 작업을 수행하는 쪽은 Visitor 클래스의 서브 클래스

연산의 이름은 좀더 범용적인 Visitor 인터페이스를 따라야 한다.

새로운 분석 작업을 추가하고 싶으면 그 분석 작업을 Visitor의 서브클래스로 정의하면 끝이며, 글리프 클래스 쪽은 건드리지 않아도 된다.

 

[방문자 패턴]

이 패턴의 주요 참여자가 바로 Visitor 클래스와 서브클래스이다. Visitor 패턴은 Glyph 클래스의 변경 없이도 추가 가능성을 내포한 글리프 구조 분석을 가능하게 하려고 사용한 기법을 잡아낸 것이다. 꼭 복합 객체에만 적용할 수 있는 것이 아니라 모든 구조에 다 적용할 수 있다. 방문자가 방문하는 클래스들이 꼭 동일한 부모 클래스를 가질 필요도 없다.

방문자 패턴을 사용하기 전에 반드시 확인해야 하는 부분 하나가 있다. 가장 자주 변경되는 클래스 계층이 무엇인가 하는 것이다. 구조 클래스 구조가 안정된 상태에서 객체에게 여러 가지 일을 많이 시키고 싶다면 방문자 패턴을 사용하는 것이 좋다. 기존 클래스 구조에 새로운 (서브)클래스가 추가되면 반드시 Visitor 클래스에 Visit...() 연산을 추가해야 한다는 것을 잊지 말아야 한다.

 

[2.9 요약]

1.문서의 물리적 구조를 표현하기 위한 복합체 패턴

2.서로 다른 서식 설정 알고리즘을 위한 전략 패턴

3.사용자 인터페이스를 꾸미기 위한 장식자 패턴

4.여러 개의 룩앤필 표준을 지원하기 위한 추상 팩토리 패턴

5.여러 개의 윈도우 플랫폼을 허용하기 위한 가교 패턴

6.취소 가능한 사용자 연산을 위한 명령 패턴

7.객체 구조를 접근하고 순회하기 위한 반복자 패턴

8.문서 구조의 구현을 복잡하게 하지 않고 다수의 분석 기능을 제공하기 위한 방문자 패턴

반응형

댓글