지난 호까지는 객체 생성에 대한 하나의 문제에 대하여 다양한 각도에서의 해결책을 제시하는 여러 가지 패턴에 대해서 알아보았다. 디자인 패턴을 다루고 있는 거개의 책들은 이들 패턴을 묶어서 Creational patterns[1][2]의 범주에 넣는다(뉴스레터 5호의 Object Lifecycle Manager 패턴은 기존의 객체 생성 패턴을 보완한다는 관점에서 Creational patterns의 범주에 넣을 수 있다고 생각한다).
이 번호부터는 좀더 다른 각도에서 문제를 찾아 해결하고 있는 디자인 패턴에 대해서 이야기해 보려고 한다. 아마 객체 생성보다도 더 재미있는 이야기가 될 것으로 생각된다.
1. 생성된 객체들 사이의 관계
어떤 시스템을 객체지향적으로 디자인 한다는 것은 무엇을 의미하는가? Grady Booch나 James Rumbaugh와 같은 객체지향 방법론(methodology)의 대가들이 만들어 놓은 이론을 따르지 않더라도, 직관적으로 어느 정도는 누구나 쉽게 생각해 볼 수 있는 수순이 있다. 먼저, 풀고자 하는 문제를 분석하고 이를 바탕으로 필요한 객체를 찾아낸 후에 이들 객체 사이의 관계(association)를 정립하는 것이다. 이 때, 객체들 사이의 관계는 해당 시스템의 행위(behavior)를 결정짓게 된다. 거꾸로 이야기 해서, 어떤 기대되는 행위를 하는 시스템을 설계하기 위해서는 분석 과정을 통해서 필요하다고 판단되는 객체들 사이에 어떤 관계가 성립되어야 하는가를 정확하게 명시해 주어야 한다. 이 것이 잘못되면, 엉뚱한 행위를 하는 시스템을 탄생시킬 수 있을 것이다.
사실 지금까지 이야기되어 왔던 Creational patterns의 범주에 들어있는 패턴들도 객체 생성이라는 행위를 하기 위해서 여러 개의 객체들이 어떤 특별한 관계를 가지고 구성되어 있음을 확인할 수 있다. 디자인 패턴 중에는 (필자가 판단하기에) 행위 자체의 중요성으로 인해서 Behavioral patterns라는 범주에 들어있는 것들이 있다. 도대체 어떤 행위를 하길래 범주 자체의 이름이 ‘행위’라는 것에 포함시켜 놓았을까라는 의문을 제기해 볼 수도 있을 것이다. 이 번호부터는 Behavioral patterns 범주에 들어 있는 디자인 패턴들에 대해서 이야기를 해 보려고 한다. 그 첫번째로 Observer 패턴을 선택하여 보았다.
2. 도대체 무엇을 관찰한다는 것인가?
Observer 패턴의 이름에서 유추해 볼 수 있듯이 이 패턴은 하나의 객체가 다른 객체를 관찰하는 것이다. 그럼 무엇을 관찰한다는 것이며, 왜 관찰하는 것인가?
어떤 시스템을 디자인하다 보면, 어떤 객체의 행위가 다른 객체의 상태 변화에 의존하는 경우가 많이 있다. 예를 들어서, 우리가 일반적으로 많이 사용하고 있는 네트웍 채팅 시스템의 경우를 보더라도, 채팅 클라이언트는 채팅 서버에 새로운 메시지가 도착했는지의 여부를 지속적으로 관찰하고 있다가, 새로운 메시지가 도착해 있으면, 채팅을 하고 있는 사람에게 새로운 메시지를 누가 타이핑했는지를 알려주는 기능이 필요하다. 이런 예를 들지 않아도, 경험이 많은 프로그래머들은 이런 종류의 행위가 얼마나 자주 시스템 내에서 필요한지 알고 있을 것이다. 그럼 이런 기능을 어떤 식으로 디자인해야 잘 했다고 소문이 날까?
3. 세 가지 방법
한 객체가 다른 객체의 상태의 변화를 관찰하여 어떤 기대하고 있는 변화가 일어나면 어떤 행위를 하는 이런 종류의 행위는 디자인 관점에서 크게 세 가지의 방법을 생각해 볼 수 있다. Polling, 동기식(syncronous) 방법, 비동기식(asyncronous) 방법이 그것이다.
각각의 방법이 무엇을 의미하는지 알아보기 위해서 위에서 예로 들었던 채팅 시스템의 경우를 가지고 이야기해 보겠다. 채팅 클라이언트는 채팅서버에 자신이 참여하고 있는 채팅 그룹 내의 어떤 채팅 클라이언트로부터 새로운 메시지가 도착했는지를 확인해서, 도착했으면 그 새로운 메시지를 채팅을 하고 있는 사용자에게 보여주는 행위가 기본적으로 필요하다. 이런 기능에 대한 디자인으로 가장 쉽게 생각해 볼 수 있는 것은 채팅 클라이언트가 주기적으로 채팅 서버에 접속해서 속해 있는 채팅 그룹내의 누군가가 새로운 메시지를 타이핑했는지를 확인해 보는 것이다. 이런 방법을 polling이라고 부른다. 경우에 따라서, polling을 사용해서 시스템을 디자인 해야 할 경우가 있지만, 경험적으로는 그리 좋은 방법은 아니다. 이 예의 경우를 보더라도, 채팅 클라이언트는 채팅 서버에 새로운 메시지가 들어와 있던 그렇지 않던 간에 주기적으로 서버를 점검하는 행위를 하는데 결과적으로는 불필요한 네트웍 트래픽을 유발시키며 시스템의 자원을 남용하는 문제를 야기시킬 수 있다.
서버에 새로운 메시지가 도착했는지의 여부를 확인할 수 있는 polling외의 또 다른 방법으로는 새로운 도착 메시지 제공을 목적으로 서버에서 제공하는 인터페이스를 클라이언트에서 동기적으로 호출하는 것이다. 이 경우에는 이 인터페이스를 호출한 클라이언트는 서버에 새로운 메시지가 도착해서 그 메시지를 리턴해 주기 전까지는 계속 해당 인터페이스의 호출에 묶여 있게 된다. 즉, 클라이언트는 서버에 새로운 메시지가 도착해서 호출한 인터페이스가 리턴되기 전까지는 다른 일을 할 수 없는 상태에 빠져 있게 된다. 따라서, 이 방법도 그리 효과적인 방법은 아니다.
다른 방법으로는 클라이언트가 서버에 접속한 후에 같은 채팅 그룹에 속해 있는 사람이 메시지를 서버에 보내면, 나에게도 그 메시지를 보내달라고 요청하는 방법이 있다. 이 방법은 서버에서 이런 목적으로 제공하는 인터페이스를 비동기적으로 호출함으로써 이루어지며, 이 방법은 callback 이라고 불리워지고 있다. 그 이유는 내가 call을 했는데, 지금 당장은 메시지가 없으니, 나중에 메시지가 도착하면, 나에게 알려달라고 나의 연락처를 남기는 과정이라고 해서 callback이라고 이름을 붙였다고 한다. callback은 많이 사용되고 있는 방법으로 프로그래밍언어를 설명하는 거개의 책들은 별도의 섹션을 마련해서 해당 프로그래밍언어로 callback을 어떻게 구현할 수 있는지 설명하고 있는 정도이다. 패턴 저자들이 이런 callback을 가만히 놓아두었을리가 없다. 디자인 패턴에서는 callback을 Observer 패턴이라고 이름 붙여서 정리해 놓았다.
두 번째 방법은 단순히 서버에서 제공하는 인터페이스를 동기적으로 호출하는 것이므로 특별히 이야기할 것은 없다. 다음 절에서는 callback을 패턴으로 정리한 observer 패턴을 polling과 비교하여 이야기하기 보겠다.
4. Polling
참고문헌 [3]에는 polling이 다음과 같이 정의되어 있다.
"Polling" describes a situation in which a client repeatedly, usually in a loop, invokes a method on another object to see if anything has changed.어떤 클라이언트가 (보통은 루프를 이용해서) 지속적으로 다른 객체의 상태 변화를 알아보려는 목적에서 그 객체가 제공하는 메소드를 지속적으로 호출하는 것을 polling이라 한다.
위에서 예로 들었던 채팅 시스템을 가지고 polling에 대해서 좀더 구체적으로 알아보자. 채팅 클라이언트는 메세지를 서버에 보내고 받을 수 있어야 하지만, 이야기를 단순화 시키기 위해서 본 글의 목적상 메세지를 서버에서 받는 기능에 대해서만 이야기하려 한다. 다음은 polling을 이용해서 채팅 시스템을 구현한 간단한 자바 소스이다.
public class Message {
...
}public class ChatServer {
...
private boolean newMsg = false;
private Message msg;
...
public boolean isNewMsg() {
return newMsg;
}
...
public Message getMsg() {
return msg;
}
}public class ChatClientGet implements Runnable {
...
private Message msg_;
private ChatServer chatServer_;
...
public ChatClientGet(ChatServer cs) {
chatServer_ = cs;
}
...
public void run() {
while(true) {
boolean isNewMsg = chatServer_.isNewMsg();
if(isNewMsg) {
msg_ = chatServer_.getMsg();
// do something..
}
}
}
실력있는 프로그래머라면 위의 소스가 많은 문제를 가지고 있다는 것을 금방 알아차렸을 것이다. 우선 많은 문제점을 뒤로 한채 polling에만 초점을 맞추어서 위의 소스를 보자.위의 소스를 보면 채팅서버 ChatServer는 isNewMsg()라는 인터페이스를 두어서 채팅 서버에게 새로운 메세지가 서버에 도착되어 있는지에 대한 정보를 제공하고 있고, getMsg()라는 인터페이스를 통해서는 서버에 있는 메세지를 클라이언트에게 전달하고 있다. 채팅 클라이언트 ChatClientGet은 서버에서 제공하고 있는 두 개의 인터페이스를 통해서 새로운 메세지가 서버에 도착되어 있는지를 확인한 후에, 새로운 메세지가 있으면 그 해당 메세지를 받아온다. 소스를 전체적으로 다시 보면, polling 방법을 이용했을 경우에 새로운 메세지가 서버에 도착된 후에 모든 행위의 책임이 클라이언트에 집중되어 있다. 서버는 단지 새로운 메세지가 도착되어 있다는 상태 정보와 해당 메세지를 클라이언트가 받아갈때까지 저장하는 기능만을 가지고 있고, 새로운 메세지가 도착되어 있다는 정보를 클라이언트에 전달하는 기능과 해당 메시지를 클라이언트에 전달하는 기능이 모두 클라이언트의 책임으로 되어 있다. 즉, polling 방법을 사용한다는 것은 다른 객체의 상태에 의존하고 있는 어떤 객체의 부담을 크게 하는 방법이다. 이런 이유로 해서, polling 방법을 이용해서 어느 정도 원활하게 돌아가는 채팅 시스템을 디자인하기위해서는 고려해주어야 할 것이 아주 많아지고 시스템은 그만큼 복잡해 진다. 예를 들어, polling방법을 이용하여 구현되어 있는 위의 소스가 어느 잘(?) 돌아가게 만들려면 적어도 다음과 같은 것들이 고려되어야 할 것이다.
- 클라이언트의 polling 행위 사이에 여러 개의 메세지가 도착할 수 있다는 것.
- 세명 이상의 사람이 채팅을 할 경우에 각 메세지가 해당 그룹의 모든 사람에게 전달되었는지에 대한 정보 관리가 서버측에 필요하다는 것.
- 클라이언트 측에서는 바로 전에 어떤 메세지까지 받았는지에 대한 정보 관리
- 등등...
어떤가? polling을 이용해서 디자인된 채팅 시스템을 구현할 수는 있지만, 결과적으로 괴물(?)과 같은 시스템이 탄생할 것이 분명하다. 다음에는 채팅 시스템을 좀 더 단순하게 디자인 할 수 있게 해 주는 Observer 패턴에 대해서 알아보겠다. 앞에서도 이야기 했듯이 Observer 패턴은 callback 방법을 패턴화 시킨 것이다.
5. Observer 패턴
먼저 Observer패턴이 어떻게 생겼는지 보자. 그림 1은 Grand[2]가 GoF 책의 Observer 패턴을 조금 수정한 것이다. 개인적으로는 GoF책에 있는 것보다 더 의미가 분명한 것 같아서 Grand의 것을 Observer 패턴으로 여기에 소개한다. 그림 1을 보면 지금까지 봐왔던 다른 여느의 패턴들처럼 그 구조가 복잡하지 않다는 것을 알 수 있다.
그림 1. Observer 패턴
이 패턴의 주요 객체는 Observer와 Observable이다. 지난 호들에서 누누히 이야기해 왔듯이 이 두 객체는 서로의 의존성을 줄이기 위해서, ObserverIF와 ObservalbleIF라는 이름의 interface들을 사이에 두어 서로의 관계를 맺고 있다. Observer 객체가 Observable 객체에게 제공하고 있는 인터페이스로 notify()가 있고, Observable객체가 Observer 객체에게 제공하고 있는 인터페이스로는 addObserver()와 removeObserver()가 있다. Observer가 Observable이 제공하고 있는 addObserver() 인터페이스를 통해서 자신이 관찰하고자 하는 객체에 상태변화시에 알려달라는 요청(call)을 한다. 그러면, Observable 객체는 자신의 상태 변화가 생길때, Observer가 제공한 notify() 인터페이스를 이용해서 요청한 Observer에게 그 사실을 알려주는 것이다(callback). 즉, callback을 표현하는 디자인 패턴이다. 그러나, 그림 1에 보면 Observer의 등록과 notification의 일은 Observable 객체가 하고 있는 것이 아니라, Observable 객체는 이 일을 Muticaster라는 객체에 위임(delegation)하고 있다. 사실 Observable 객체가 할 일을 다른 객체에 구지 위임할 필요성은 없지만, 이렇게 함으로써 얻을 수 있는 장점이 있다. 그 장점은 ObservableIF를 구현하고 있는 모든 Observable객체들이 그 코드를 재사용할 수 있다는데 있다. Observable 객체에 등록한 Observer객체가 둘 이상인 경우에 이들 Observer객체들에게 Observable객체가 메시지를 보내는 형태는 multicasting 형태이므로 Observable 객체의 할 일을 위임받은 객체의 이름을 Multicater라고 지은 것이고, 이런 이유로 Observer패턴은 multicast callback을 패턴화 한 것이라고 이야기되어 진다.
그럼 이 패턴을 이용하면 위에서 예로 들어 설명해 왔던 채팅 시스템이 어떻게 디자인되고 구현될 수 있는지 이야기해 보겠다. 우선 Observer 패턴을 적용한다면 간단한 채팅시스템을 그림 2와 같은 클래스 다이어그램으로 표현할 수 있을 것이다.
그림 2. multicast callback을 적용한 채팅시스템의 클래스 다이어그램
그림 2의 Observer 패턴을 사용한 디자인을 보면 polling을 시스템 디자인에 적용했을 경우와 비교해서 그 차이가 많이 나타나고 있다. polling을 적용했을 때와는 달리 callback을 적용한 경우에는 클라이언트는 메세지 수용에 있어서 수동적이 된다. 즉, 서버에 자신을 등록시켜놓은 이후에는 서버에서 새로운 메세지를 전달해줄 때, 그 해당 메세지를 전달받을뿐, 서버에 새로운 메세지가 도착되어 있나 확인하는 일련의 작업을 하지 않고 있다. 따라서, 클라이언트는 서버로부터의 새로운 메세지 도착여부에 상관없이 다른 일을 하고 있다가 서버로부터 새로운 메세지가 도착했다는 메세지 notity(Message)를 받으면 이에 상응하는 일을하면 된다. 결과적으로 Observer 패턴으로 디자인된 시스템은 메시지 전달에 대한 책임이 클라이언트로부터 서버쪽으로 넘어갔으며, polling의 경우에 문제가 되었던 서버로부터 받은 메세지 리스트 정보를 일일이 저장하여 비교하는 불합리한 점들이 모두 사라지게 된다. 결과적으로 Observer 패턴을 사용하면 다른 객체의 상태에 대한 의존성을 가지는 객체들의 행위를 간단하게 디자인하고 구현할 수 있을 것이다.
그림 2처럼 디자인된 채팅시스템의 간단한 구현 소스는 다음과 같이 될 수 있을 것이다.
pubic interface ChatObserver {
pubic void notify(Message msg);
}
public class ChatClientGet implements ChatObserver {
...
private Message msg_;
...
public void notify(Message msg) {
msg_ = msg;
}
...
}
public interface ChatObservable {
public void addObserver(ChatObserver co);
public void removeObserver(CharObserver co);
}
public class ChatServer implements ChatObservable
extends Thread {
...
private Multicaster mCaster_;
...
public ChatServer() {
...
mCaster_ = new Multicaster();
...
}public void addObserver(ChatObserver co) {
mCaster_.addObserver(co);
}public void removeObserver(ChatObserver co) {
mCaster_.removeObserver(co);
}
...
public void run() {
while(true) {
// 메세지 도착 여부를 모니터링한다.
// 새로운 메세지가 도착하면 notify() 메소드를 호출한다.
mCaster_.notify(msg);
}
}
}
public class Multicaster {
...
private ArraySet observers_ = new ArraySet();
...
public void addObserver(ChatObserver co) {
observers_.add(co);
}public void removeObserver(ChatObserver co) {
observers_.remove(co);
}
...
public void notify(Message msg) {
Iterator it = new observers_.iterator();
while(it.hasNext()) {
((ChatObserver)it.next()).notify(msg);
}
}
...
}
이 패턴의 저자들인 GoF 들이 이 패턴에 대해서 밝히고 있는 의도(intent)로 Observer 패턴에 대한 이야기를 줄이겠다.
의도(intent)
Define a one-to-many dependency between objects so that when one object changes states, all its dependents are notified and updated automatically.
6. 관련 패턴객체들 사이에 일대다 의존성을 부여할 때 사용될 수 있는 패턴으로써 하나의 객체 상태가 바뀌면 그 객체에 의존하고 있는 모든 객체가 그 사실을 통보받고 그에 해당하는 행위를 할 수 있게 한다.
이 패턴의 저자들이 Observer 패턴과 관련이 있다고 이야기한 패턴으로 Mediator [1]패턴이 있다. 구체적으로 Mediator 패턴이 Observer 패턴과 무엇이 비슷하며 차이점은 무엇인지 알아보는 것도 재미있을 것 같다. 특별히 흥미로운 것이 발견되지 않으면 다음에는 Mediator 패턴에 대해서 이야기를 해 볼까 한다.
7. 맺음말
이 번호에 소개한 Observer패턴은 multicast callback을 패턴화 한 것으로 경험이 어느 정도 있는 시스템 디자이너와 프로그래머들은 익히 잘 알고 있는 내용이었을 것으로 생각된다. 바꾸어 이야기하면, Observer 패턴은 어떤 시스템을 디자인 할 때 아주 유용하게 사용될 수있는 패턴 중에 하나이다. 뭐, 사실 별 어려운 내용이 아니지만, 이런 작은 것들이 모여서 전체 컴퓨터 시스템을 견고하고 실용적이고 확장에 편리하고 아름답게(?) 만드는 것이 아닐까 생각해 본다.
얼마전에 어느 독자가 자신이 관심을 두고 있는 XML 분야에 자주 나타나는 내용을 패턴으로 정리하고 싶은데, 어떻게 하면되느냐고 필자에게 질문을 한 적이 있다. 그 분에게 답하기를 Gerard Meszaros 과 Jim Doble의 "A Pattern Language for Pattern Writing"을 읽어보는 것이 좋을 것 같다고 했는데, 지금 이 글을 준비하면서 생각해보니, 바로 Observer 패턴을 읽어보는 것이 더 좋은 것 같다는 생각이 든다. 왜냐하면, 일반적으로 많이 사용되고 있는 callback을 패턴화 시킨것이므로 패턴 글쓰기를 이해하는데 더 쉽게 접근할 수 있을 거란 생각에서이다.
참고 문헌
[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides,
Design Patterns, Elements of Resuable Object-Oriented
Software, Addison-Wesley, 1995[2] Mark Grand, Patterns in Java, volume 1, Wiley, 1998
[3] Nigel Warren, Philip Bishop, Java in Practice, Design Styles and
Idioms for Effective Java, Addison-Wesley, 1999
(글 후기 )
PLoP 2000 컨퍼런스에 제출했던 제 논문을 공개한다 하면서도 계속 늦장을 부렸는데.. 우선 죄송하다는 말씀을 드립니다. 사실 아직 한글화 작업은 하지 못했습니다. 이 글을 쓰기 바로 전날까지도 제 논문에 대한 수정이 있었기 때문입니다. 그 이유는 기쁘게도 제 논문이 채택이되서 final conference copy를 위한 마지막 수정 작업이 있었거든요 그러나 더 이상 미룰 수 없다는 생각에서 한글화된 논문은 다음의 기회로 미루고, 우선은 영문 논문을 그대로 이 번호의 객체지향뉴스레터에 공개합니다. 관심있으신 분들은 많이 읽어 보시고요, 많은 comment부탁드립니다. ^(^
oonewsletter - 2000/7/29