<div id="readability-page-1" class="page"><div>
 
 <article>
 <ul id="markdown-toc">
 <li><a href="#의도" id="markdown-toc-의도">의도</a></li>
 <li><a href="#구조" id="markdown-toc-구조">구조</a></li>
 <li><a href="#사례" id="markdown-toc-사례">사례</a> <ul>
 <li><a href="#마우스-포인터-포커스-처리" id="markdown-toc-마우스-포인터-포커스-처리">마우스 포인터 포커스 처리</a></li>
 <li><a href="#gof-gui-애플리케이션의-문맥-도움말-기능" id="markdown-toc-gof-gui-애플리케이션의-문맥-도움말-기능">GoF: GUI 애플리케이션의 문맥 도움말 기능</a></li>
 <li><a href="#xml-태그-생성기" id="markdown-toc-xml-태그-생성기">XML 태그 생성기</a></li>
 </ul>
 </li>
 <li><a href="#참고문헌" id="markdown-toc-참고문헌">참고문헌</a></li>
 <li><a href="#주석" id="markdown-toc-주석">주석</a></li>
</ul>

<h2 id="의도">의도</h2>

GoF 책에서는 다음과 같이 의도를 설명한다.

<blockquote>

 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴입니다.
하나의 요청에 대한 처리가 반드시 한 객체에서만 되지 않고, 여러 객체에게 그 처리 기회를 주려는 것입니다.
<a href="#fn:gof-298" rel="footnote">1</a>
</blockquote>

<h2 id="구조">구조</h2>

<img src="https://johngrib.github.io/resource/E7/72F156-8273-4CA8-A3A7-13EB09B5699A/structure.svg" alt=""> <a href="#fn:gof-301" rel="footnote">2</a>

<blockquote>

 <ul>
 <li>Handler(HelpHandler):의 요청을 처리하는 인터페이스를 정의하고, 후속 처리자(successor)와 연결을 구현합니다. 즉, 연결 고리에 연결된 다음 객체에게 다시 메시지를 보냅니다.</li>
 <li>ConcreteHandler(PrintButton, PrintDialog): 책임져야 할 행동이 있다면 스스로 요청을 처리하여 후속 처리자에 접근할 수 있습니다. 즉, 자신이 처리할 행동이 있으면 처리하고, 그렇지 않으면 후속 처리자에 다시 처리를 요청합니다.</li>
 <li>Client: ConcreteHandler 객체에게 필요한 요청을 보냅니다.
<a href="#fn:gof-302" rel="footnote">3</a></li>
 </ul>
</blockquote>

<h2 id="사례">사례</h2>

<h3 id="마우스-포인터-포커스-처리">마우스 포인터 포커스 처리</h3>

'실용주의 디자인 패턴'에서는 마우스가 움직일 때 포커스를 받은 각 객체들이 다르게 작동하는 것을 사례로 소개한다.

책임연쇄 패턴의 '단점'을 소개하는 사례이지만, 책임연쇄 패턴의 핵심을 이해하기 쉽게 잘 설명해 준다.

<blockquote>

 마이크로소프트 윈도에서는 마우스가 1픽셀 움직일 때 <code>WM_MOUSEMOVE</code> 메시지가 우선 포커스를 받은 Window에 전달된다.
만약 이 컨트롤이 메시지를 어떻게 처리해야 하는지를 모른다면 이 메시지를 자신을 포함하고 있는 패널로 전달하고,
이러한 과정이 MDI 윈도, 메인 프레임, 메뉴 바, 메뉴 바의 각 메뉴 아이템으로 반복된다.
이때 어떤 객체도 메시지를 처리할 수 없으면 메시지를 버리게 된다.
많은 일을 했지만 아무런 일도 벌어지지 않는다.
<a href="#fn:holub-472" rel="footnote">4</a>
</blockquote>

<h3 id="gof-gui-애플리케이션의-문맥-도움말-기능">GoF: GUI 애플리케이션의 문맥 도움말 기능</h3>

다음은 GoF 책에서 소개하는 사례이다.

<blockquote>

 그래픽 사용자 인터페이스(GUI)에 있는 문맥 감지 도움말(context-sensitive help) 기능을 생각해 봅시다.
사용자가 정보를 선택하면 그 부분에 대한 도움말 정보를 얻을 수 있습니다.
그러나 도움말의 내용은 선택한 주체가 무엇이며, 현재 그 주체의 상황이 어떠한가에 따라 다를 수 있습니다.
즉, 대화상자 내에 있는 버튼 위젯은 기본 위도우에 있는 버튼과 내용이 다른 도움말을 제공해야 합니다.
만약, 선택한 주체에 대한 구체적인 도움말이 없다면,
도움말 시스템은 적어도 응용프로그램이 정의한 일반적인 도움말이라도 제공할 수 있어야 합니다.

 따라서 도움말 정보는 구체적인 내용부터 일반적인 내용까지 내용의 일반성에 따라서 구성하는 것이 자연스럽습니다.
게다가, 도움말에 대한 요청은 여러 사용자 인터페이스 객체 중 어느 하나로 처리된다고 보는 게 명확합니다.
즉, 도움말 요청이 어떤 상황에서 발생했는지에 따라서, 요청을 받은 객체가 직접 그 요청을 처리하지 않을 수도 있습니다.
어느 정도의 구체적인 도움말이 가능한가에 따라 여러 인터페 이스 중 하나가 이 요청을 처리할 수 있습니다.
허나, 문제는 궁극적으로 도움말을 제공해야 할 객체가 도움말 요청을 보내는 객체(예를 들어, 버튼 같은 인터페이스 객체)에게 알려져 있지 않다는 것입니다.
즉, 요청을 일으키는 객체는 실제로 자신에게 해당 도움말을 제공하는 객체가 누구인지 알 수 없다는 것입니다.
이를 위해서 우리는 도움말 요청을 발생시키는 버튼과 도움말 정보를 제공하는 객체를 분리해야 할 필요가 있습니다.
이 부분의 기작을 정의하는 패턴이 바로 책임 연쇄 패턴입니다.

 <img src="https://johngrib.github.io/resource/E7/72F156-8273-4CA8-A3A7-13EB09B5699A/context-help.svg" alt=""> <a href="#fn:gof-298" rel="footnote">1</a>
</blockquote>

다이어그램을 보면 이해하기 좋다.

도움말 기능을 켠 다음, <code>OK</code> 버튼을 선택한 상황이라 하자.
이 때, <code>OK</code> 버튼의 기능은 누가 봐도 명백해서 딱히 도움말이 마련되어 있지 않다고 상상해 보자.

<ol>
 <li>도움말 기능은 <code>OK</code> 버튼의 <code>handler</code>에 도움말을 요청한다.</li>
 <li><code>OK</code> 버튼이 도움말을 제공하지 않으므로, <code>handler</code>는 요청을 다음 객체로 전달한다.</li>
 <li>요청이 <code>PrintDialog</code>로 전달된다.</li>
 <li>도움말 기능은 <code>PrintDialog</code>의 <code>hander</code>에 도움말을 요청한다.</li>
 <li><code>PrintDialog</code>가 제공하는 도움말이 출력된다.</li>
</ol>

<h3 id="xml-태그-생성기">XML 태그 생성기</h3>

'패턴을 활용한 리팩터링'에서는 XML 태그 생성기를 사례로 소개한다.

<blockquote>

 <div><pre><code>public class TagBuilderTest...
 public void testRepeatingChildrenAndGrandchildren()...
 ...
 TagBuilder builder = new TagBuilder("flavors");
 for (int i = 0; i &lt; 2; i++) {
 builder.addToParent("flavors", "flavor");
 builder.addChild("requirements");
 builder.addChild("requirement");
 }
 assertXmlEquals(expectedXml, builder.toXml());
</code></pre></div>
</blockquote>

<blockquote>

 <code>addToParent()</code>를 구현하는 방식은 다음과 같다.
원하는 부모 노드의 이름을 파라미터로 받고, <code>TagBuilder</code>의 <code>currentNode</code> 노드의 이름과 비교한다.
이름이 일치하면 <code>currentNode</code> 노드에 새 자식 노드를 추가한 후 끝내면 되고,
그렇지 않으면 <code>currentNode</code> 노드의 부모를,
그리고 또 그 부모를 계속 따라 올라가며 이름이 일치하는 노드를 만나거나 혹은 널을 만날 때까지 계속 비교하는 것이다.
참고로 이런 방식을 Chain of Responsibility[DP] 패턴이라 한다.
<a href="#fn:joshua-156" rel="footnote">5</a>
</blockquote>

<h2 id="참고문헌">참고문헌</h2>

<ul>
 <li>GoF의 디자인 패턴(개정판) / 에릭 감마, 리처드 헬름, 랄프 존슨, 존 블라시디스 공저 / 김정아 역 / 프로텍미디어 / 발행 2015년 03월 26일</li>
 <li>실전 코드로 배우는 실용주의 디자인 패턴 / Allen Holub 저 / 송치형 편역 / 사이텍미디어 / 발행 2006년 07월 19일 / 원제 : Holub on Patterns : Learning Design Patterns by Looking at Code</li>
 <li>패턴을 활용한 리팩터링 / 조슈아 케리에브스키 저 / 윤성준, 조상민 공역 / 인사이트(insight) / 신판 1쇄 발행 2011년 02월 09일 / 원제 : REFACTORING TO PATTERNS</li>
</ul>

<h2 id="주석">주석</h2>



 </article>


 
 
 



</div></div>

기계인간 John Grib

JohnGrib

요청을 처리할 객체가 나타날 때까지 객체 연결을 따라간다

책임연쇄 패턴 (Chain of Responsibility Pattern)

댓글