디자인 패턴(9) - 더 좋은 인터페이스를 위하여..
이승일
E-mail:gaialee@icu.ac.kr
지난 호에 Composite[1] 패턴을 인터페이스(Interface)라는 주제와 연관 지어서 생각해 보았다. 이야기가 진행되려다 만 경향이 있어서 이번 호에서는 Visitor패턴[1]이라는 것을 가지고 지난호의 2부쯤 되는 이야기를 해 보려 한다.
지난 호의 이야기 연결...
지난 호의 Composite패턴에서 method들을 composite에 주는 것과 component에 두는 것과의 차이에서 발생하는 문제를 투명성(transparency)과 안전성(safety)에 대한 관점에서 서로의 장단점을 생각해 보았다. 독자들은 저자의 이야기 진행을 어떻게 생각해 보았는지 모르겠다. 지난 호에서 다루었던 두 가지 관점을 좀더 자세히 살펴보면, 다른 흥미로운 이야길 거리를 찾을 수 있다. 먼저, 투명성에 대해서 보자. 컴퓨터 시스템 디자이너 또는 프로그래밍을 공부했던 독자들은 보아왔던 많은 책에서 투명성에 대해서 이야기하고 있는 것을 발견했을 것이다. 어떤 모듈이 외부에 인터페이스를 제공한다는 것은 무엇을 의미하는가? 이것은 해당 모듈의 내부 속사정을 되도록이면 숨기려는 노력의 일환이라고 생각할 수 있다. 객체지향 관점에서는 이것을 다른 용어로 ‘information hiding’이라고 이야기되어 지기도 한다. 그리고, information hiding의 좀 더 구체적인 방법은 encapsulation과 abstraction이라고 이야기를 하면서 우리들의 머리속을 어지럽게 만든다. encapsulation이 잘된 모듈은 외부의 클라이언트에게 최소한의 인터페이스만을 제공하면서 내부의 속사정을 가능한 알 수 없게 함으로써 클라이언트와의 관계를 최소화 시키고, 결국 잘 디자인된 모듈이라는 소리를 듣는다. 많은 문서에서 언급하기 때문에 익숙하지만 이해하기 쉽지 않은 용어로는 이를 ‘low coupling’을 실현시키고 있는 모듈이라고 불린다. Abstraction이 의미하는 것도 encapsulation과 의미상으로 거의 비슷하게 이해되어 지고 있다[2]. Encapsulation이 강제적으로 내부의 속사정을 클라이언트가 볼 수 없게 만드는 것이라면, abstraction은 자연스럽게 이러한 목적을 이루는 것이라 볼 수 있을 것 같다. 방법은 해당 모듈이 가지는 의미를 아주 잘(?) 인터페이스로 추상화 시킴으로써 클라이언트가 해당 모듈에서 제공하는 인터페이스 외에 다른 정보를 알 필요가 없게 만드는 것이다. Encapsulation에서와 마찬가지로 잘 알려진 용어로 이런 목적을 달성한 모듈을 ‘high cohesion’되었다고 하며, 상당히 디자인이 잘 된 모듈로 칭송(?)을 한다. 정리하면, 좋은 시스템은 low coupling과 high cohesion으로 무장되어 외부에 의미를 잘 드러낸 간결한 인터페이스를 제공하는 모듈들로 이루어진 것이라고 많이들 이해하고 있는 것 같다[2].
사실 지금까지의 이야기가 너무 추상적이다. 도대체 어떻게 하면 encapsulation과 abstraction이 좋은 모듈을 설계할 수 있는 것일까? 필자의 생각으로는 이를 위한 어떤 명확한 공식과 같은 방법론이 있는 것은 아니고, 많은 시스템 디자인 경험만이 있을 뿐이다라고 생각한다. 왜냐하면, 최적의 인터페이스라는 것은 상황에 따라서 달라지기 때문이다. 이런 의미에서, 디자인패턴은 경험 많은 다국적 선배들의 노하우가 쌓인 디자인 해답이기 때문에 훌륭한 자원이 될 수 있다. 다시 말하면, 어떤 문제가 이런 상황에서는 이렇게 해결되는 것이 최선이 될 수 있다라는 검증된 디자인으로 볼 수 있기 때문이다.
어떻게 할까?
지난 호에 composite 패턴을 이용해서 간단하게 디자인 했던 파일 시스템을 다시 상기시켜보자[그림 1]. 지난 호에 디자인 했던 파일 시스템에서 외부에 제공하고 있는 인터페이스를 가지고 할 수 있는 일은 새로운 디렉토리나 파일 첨가, 삭제와 Node의 이름 보기를 할 수 있다. 따라서, 이 파일 시스템에서 제공되는 인터페이스를 이용하면 파일 시스템에 들어있는 파일과 디렉토리의 이름보기의 간단한 ls와 같은 응용프로그램을 만들 수 있다. 너무 간단하다 싶어서, 디렉토리는 이름 뒤에 “/”가 표시될 수 있도록 하고 싶다는 생각을 했다고 가정해 보자. 어떻게 해야 할까?
그림 1. Composite 패턴을 적용한 파일 시스템 디자인
파일은 그대로 이름을 출력하고 디렉토리는 이름 뒤에 “/”가 출력되어야 하는 문제는 해당 node의 타입에 따라서 달라지게 된다. 가장 쉽게 생각할 수 있는 디자인 방법은 File node와 Directory node의 getName()을 서로 다르게 구현하는 것이다. 너무 간단한가? 여기서 우리가 주의 깊게 봐야 할 사항이 있다. 이 방법은 기존의 파일 시스템의 node들의 method를 수정하고 새롭게 컴파일하는 과정을 거치게 된다. 예제가 기존에 존재하는 인터페이스의 구현을 서로 다르게 하는 것으로 끝나는 아주 간단한 것이어서 그렇지, 아예 새로운 operation을 도입해야 하는 문제에 당면했을 경우에는 그리 간단하지 않다. 지난 호에서 고민에 빠졌던 문제가 다시 대두되는 것이다. 새로운 기능을 인터페이스의 operation으로 추가할 것인가 아니면 각 node의 타입의 method로만 둘 것인가 하는 문제로 말이다. 파일 시스템에 새로운 기능을 추가할 때마다 이런 고민을 하는 것도 힘든 일인데, 추가되는 기능을 위한 인터페이스의 operation의 증가로 전체 파일 시스템의 encapsulation과 abstraction이 떨어져서 나중에는 도저히 감당할 수 없을 정도로 파일시스템이 복잡해져서 인터페이스라는 의미가 무색해 질 것이다. 따라서, 파일 시스템의 기능 확장성을 위해서는 기존의 파일 시스템을 구성하는 node 구조를 수정하는 이와 같은 방법은 그리 바람직하지 않다. Node를 위한 인터페이스의 operation은 가장 기본적인 최소한의 것만을 유지하면서 node에 새로운 operation을 가할 수 있는 방법을 모색해야 할 것이다.
Node에 새로운 operation을 가하는 책임을 클라이언트에 일임하면 어떨까? 한 눔에
이러한 디자인은 객체지향적 사고방식을 무시하는 상당히 비효율적인 디자인 접근 방법임을 알 수 있다. 그 이유는 뻔하다. 파일 시스템을
이용하는데 유용하게 사용될 수 있는 공통된 기능을 모든 클라이언트 마다 구현함으로써 재사용성과 투명성을 아주 무시해 버리기 때문이다.
이 곳에서 예의 경우에는 다음의 소스 1처럼 클라이언트는 해당 node의 타입을 구별하는 과정을 거치게 되어 지난 호에서 이야기했던
투명성을 떨어뜨린다.
void ls(Node n_) {
if(n_
instanceof File)
{
System.out.println(n_.getName());
}else
if(n instanceof Directory)
{
System.out.println(n_.getName()
+
"/");
for(int
i=0; i < ((Directory)n_).getSize();
i++)
System.out.println(n_.getChild(i).getName()
);
}
}
소스 1. ls 구현 #1
그럼 이런 문제점을 어느 정도 극복할 수 있는 다른 디자인 방법은 없나?
Visitor 패턴
Visitor 패턴이 그 한가지 해답이 될 수 있다. Visitor 패턴이 어떤 것인지에 대한 일반적인 이야기는 나중에 하기로 하고, 일단 다음의 내용을 읽어보기 바란다.
Node에 새로운 operation인 accept(Visitor v)를 첨가한다. 그리고 난 후에 다음과 같은 Visitor 클래스를 정의한다.
class Visitor {
void
visit(File file_)
{
System.out.println(file_.getName());
}
void visit(Directory dir_) {
System.out.println(dir_.getName()
+
"/");
for(int
i=0 ; i < dir_.getSize(); i++)
System.out.println(dir_.getChild(i).getName());
}
}
소스2. Visitor class
그리고, Node에 새로 첨가된 accept operation에 대한 File과 Directory 의 구현부는 다음과 같이 한다.
class File extends Node
{
…
void
accept(Visitor v_)
{
v_.visit(this);
}
…
}
class Directory extends Node
{
…
void
accept(Visitor v_)
{
v_.visit(this);
}
…
}
소스3. accept method의 구현부
이제 재료(?)는 모두 준비 됐다. Node에 새로 첨가된 operation인 accept와 새로 정의한 Visitor 클래스를 가지고 소스 1과 같은 기능을 가지는 클라이언트의 method를 구현하면 다음과 같이 된다.
void ls(Node n_)
{
Visitor v_ = new
Visitor();
n_.accept(v_);
}
소스 4. ls 구현 #2
이제 소스1과 소스4를 비교해 보자. 소스1과는 달리 소스4에서는 클라이언트에서 출력하려는 해당 node의 타입을 구별하는 과정을 볼 수 없다. 대신에 새로이 추가된 accept operation을 Visitor 인스턴스의 reference만을 인자로 하여 호출하는 것이 전부이다. accept operation의 호출은 결과적으로 child의 타입에 따라서 자동으로 소스 3에서 정의된 것처럼 자신을 reference를 인자로 해서 Visitor 인스턴스의 visit 메소드가 호출된다. 그러면 소스 2에서처럼 Visitor 인스턴스의는 call back으로써 해당 node 타입에 따라getName을 호출하여, 결과적으로는 소스 1처럼 node의 타입 검사를 클라이언트에서 하지 않고도 같은 결과를 얻게 된다. visit(File file_)가 호출됬을 경우를 interaction 다이어그램으로 나타내면 다음의 sequence diagram 과 같다.
그림 2. Visitor 패턴의 sequence 다이어그램
이제 정리를 해 보자. 파일 시스템에 새로운 기능을 보강하기 위하여 accept라는 새로운 operation을 Node에 추가하기는 했지만, 소스 2에서처럼 실질적인 행위는 Visitor의 visit이라는 메소드에게 위임되어 있다. 즉, 클라이언트는 Node의 타입에 따라서 다른 형식으로 출력하는 책임을 가지는 객체를 Visitor라는 이름으로 새로 만들고, 이 객체를 전체 파일시스템을 구성하는 각 node에 accept의 인자로 넘겨주고, 각 node는 call back 형식으로 Visitor가 각 node의 이름을 해당 node이 타입에 따라서 출력하게 되어 있는 구조다.
결과적으로는 node 타입에 따른 이름 출력에 대한 책임이 Node 자체도 아니고, Node를 사용하는 클라이언트도 아닌, 제 삼의 Visitor라는 객체가 가지는 구조를 띄고 있다. 이 구조를 좀더 일반화 시키면 다음의 클래스 다이어그램과 같이 표현될 수 있다.
그림 3. 일반화된 Visitor 패턴의 활용 구조
ls를 위한 메소드외에도 파일시스템에 대한 유용한 응용프로그램으로는 Unix 시스템의 cat과 같은 것을 예로 볼 수 있다. cat의 경우에는 해당 node가 File인 경우에는 file 내용을 출력하고 directory인 경우에는 오류 메세지를 화면에 출력하는 기능을 갖추어야 한다. 이 경우에도 ls의 경우와 마찬가지로 Node의 encapsulation과 abstraction을 최적의 상태로 유지하고, 클라이언트의 부담을 덜어주기 위하여 이러한 기능을 가지는Visitor 객체를 만들어 사용하는 것을 고려해 볼 수 있다. ls와 cat 이외에도 파일시스템을 구성하는 각 node의 타입에 따라서 같은 operation에 대해서 다른 행위를 해야 하는 operation들을 생각할 수 있다. 이런 경우를 고려하여 그림 3에서처럼 Visitor 인터페이스를 두고, 실질적인 operation에 대한 행위를 구현하는 클래스들이 Visitor 인터 페이스를 implement하도록 한다. 이런 구조로 디자인하면, 클라이언트는 Node를 수정하지 않고도 Node에 대한 새로운 operation을 무한히(?) 만들어 사용할 수 있게 된다.
Encapsulation과 abstraction에 대한 느낌이 조금이나마 독자들에게 전달되었는지
모르겠다. GoF책에 있는 Visitor 패턴에 대한 구조와 의도(intent)로써 이 번호에 대한 이야기를 줄이겠다. 그림 4는
GoF책에 있는 Visitor 패턴을 필자가 조금 수정하고 UML을 사용하여 그린 다이어그램이다.
그림 4. Visitor 패턴
의도(Intent)
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
Visitor 패턴은 객체 구조체의 element에 연산을 가하는 새로운 operation을 해당 element의 클래스에 수정을 가하지 않은 상태로 추가할 수 있게 해 준다.
관련 패턴
이 패턴과 관련이 있다고 저자들이 이야기하기로는 Composite와 Interpreter 패턴이 있다. 이 번호에서는 Visitor 패턴을 Composite 패턴과 연관지어서 이야기를 해 보았고, 다음에 기회가 되면 Interpreter와 연관지어서 이야기를 해 보겠다.
맺음말
Encapsulation과 Abstraction이 좋은 객체지향 시스템을 디자인 하기는 참 어려운 일이 아닐 수 없다. 객체지향 프로그래밍 언어를 마스터 했다고 해서 할 수 있는 일도 아니고, 그야말로 많은 고민을 통해서 얻어지는 경험의 산물이라 볼 수 있을 것이다. 디자인 패턴을 잘 공부해보면, 명시적으로 잘 드러나 있지는 않지만, Encapsulation과 Abstraction이 좋은 객체지향 시스템을 디자인 하기위해서 노력한 선배들의 귀중한 경험을 공짜로 얻을 수 있을 것이다. GoF책의 내용만 대충 보지 말고, 직접 자신이 하고 있는 일에 디자인 패턴을 사용해 보기 바란다.
참고 문헌
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Elements of Resuable Object-Oriented Software, Addison-Wesley, 1995.
[2] Perdita Stevens, Using UML, Updated Edition, Addison-Wesley, 2000.
[3] John Vlissides, Pattern Hatching: Design Patterns Applied, Addison-Wesley, 1998.
(글 후기)
참 오랜 만에 글을 써 봅니다. 제가 쓴 글을 꼼꼼히 읽어보시고 더 좋은 아이디어를 주시는 분들도 계시고, 잘 못된 곳을 집어 주시는 분들도 계십니다. 제가 좀 게을러서 빨리빨리 그 내용들을 수렴하지 못한 점이 있지만, 앞으로도 제 글의 내용에 대한 좋은 지적 부탁드립니다. ^(^
이 글에삽입된 클래스 다이어그램은 “Plastic
Software”의 UML 모델링 툴인 “PLASTIC
3.0”을 이용하여그렸다.
oonewsletter -
2001/10/8