[태그:] <span>Chain of Responsibility Pattern</span>

15.1 개요 

 여러 형식 개체들로 구성된 프로그램을 작성하다 보면 메시지를 보내는 곳에서 이를 받아 처리해야 할 개체의 위치를 파악하기가 어려운 경우가 발생합니다. 만약, 메시지를 받아 처리해야 할 개체들을 관리하는 집합체가 있거나 계층화되어 있다면 책임 연쇄 패턴을 통해 효과적으로 메시지를 전달할 수 있습니다.

 책임 연쇄 패턴에서는 메시지 송신자는 이를 받아 처리해야 할 개체가 속한 집합체에 메시지를 전달하면 집합체 내에서 수신해야 할 개체에게 메시지를 전달하여 처리를 하게 하는 것입니다. 특정 개체에게 메시지가 전달되면 해당 메시지를 자신이 처리를 할 것인지를 판단을 하게 됩니다. 만약, 자신이 처리를 해야 한다면 이에 대한 처리를 하겠죠. 그리고, 해당 메시지를 처리를 해야 할 다른 개체가 존재할 수 있다면 이를 다음 개체에게 전달을 하게 됩니다. 경우에 따라서는 메시지를 변형하여 전달할 수도 있고 버릴 수도 있을 것입니다.

 즉, 책임 연쇄 패턴에서는 메시지 송신부와 메시지 수신부를 분리되어 있을 때 효과적입니다. 송신부에서는 수신부에 전달하면 수신부에서 메시지를 전달받은 개체는 자신과 연관되는 다른 개체들에게 이 메시지를 전달을 하는 형태로 실제 처리할 개체까지 전달을 하는 것입니다. 실제, 윈도우즈 프로그램에서 메시지를 처리하는 내부 원리도 이와 흡사합니다.

“책임 연쇄 패턴에서는 메시지를 수신해야 하는 개체들을 체인 형태로 연결합니다.”

15. 2 시나리오 

 지난 주에는 EH Camera의 창립 기념 행사에 참석을 하였습니다. 행사 뒤풀이에서 이 매핑 씨와 여행과 사진에 대한 얘기를 하게 되었어요. 집에서 사진 보정 프로그램을 만들어 사용하는 얘기도 하게 되었고 퍼사드 패턴을 적용하여 사진 관리와 보정에 대한 통합 모듈에 대한 얘기도 하였답니다. 그리고, 이 매핑 씨는 카메라에 새로운 영상 처리 모듈들이 추가될 때마다 사용자 설정에 맞는 각 모듈에게 영상 처리 명령을 전달하기 위해 비슷한 작업을 수행하는 비용이 많이 든다고 얘기를 하더군요. 저도 사진 보정 프로그램에 영상 처리 모듈을 추가할 때마다 비슷한 작업이 반복되는 것 같아 이를 수정할 필요성을 느끼고 있었다고 얘기를 하고 이에 대해 개발 팀과 별도로 미팅을 갖기로 했어요.

 어제는 지난 EH Camera 창림 기념 행사에서 이 매핑 씨와 했던 얘기가 생각이 나서 사진 보정 프로그램 설계를 수정해 보았습니다. 일단, UI 파트와 영상 처리 모듈 파트를 분리를 하는 작업을 하였죠. 그리고, 각 모듈들의 추상화 된 모듈을 추가하였습니다. 그리고, 이전 설계에서는 없었던 것을 하나 추가하였습니다. 다름이 아니라 영상 처리 모듈은 다른 영상 처리 모듈에게 사용자 명령을 전달할 수 있게 한 것이죠. 추상화 된 모듈을 설계하고 나서 각 모듈은 이를 기반으로 파생하게 만들고 영상 처리 모듈은 다음 등록된 영상 처리 모듈의 위치를 알게 했습니다. 이와 같이 하면 사용자가 사진 보정 명령을 내리면 UI 파트에서는 맨 앞에 있는 영상 처리 모듈에게 보정 명령을 내리고 해당 모듈에서는 자신이 처리를 할 것인지에 따라 처리를 할 수 있고 해당 명령을 다음 모듈에게 전달하는 것을 반복하게 만들면 새로운 영상 처리 모듈이 추가된다고 하더라도 프로그램을 업그레이드하는 데 비용이 줄어들 거라 생각이 되네요.

 이제, 이 매핑 씨를 만나 EH Camera 개발 팀과 이에 대한 얘기를 하러 갈게요.


 

 

설계 패턴