设计模式可复用面向对象软件的基础 第5章 行为模式.docxVIP

第5章行为模式行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。这些模式刻划了在运行时难以跟踪的复杂的控制流。它们将你的注意力从控制流转移到对象间的联系方式上来。行为类模式使用继承机制在类间分派行为。本章包括两个这样的模式。其中Te m p l a t e M e t h o d（5 . 1 0）较为简单和常用。模板方法是一个算法的抽象定义，它逐步地定义该算法，每一步调用一个抽象操作或一个原语操作，子类定义抽象操作以具体实现该算法。另一种行为类模式是I n t e r p r e t e r（5 . 3）。它将一个文法表示为一个类层次，并实现一个解释器作为这些类的实例上的一个操作。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一个对象都无法单独完成的任务。这里一个重要的问题是对等的对象如何互相了解对方。对等对象可以保持显式的对对方的引用，但那会增加它们的耦合度。在极端情况下，每一个对象都要了解所有其他的对象。M e d i a t o r（5 . 5）在对等对象间引入一个m e d i a t o r对象以避免这种情况的出现。m e d i a t o r提供了松耦合所需的间接性。Chain of Responsibility(5.1)提供更松的耦合。它让你通过一条候选对象链隐式的向一个对象发送请求。根据运行时刻情况任一候选者都可以响应相应的请求。候选者的数目是任意的，你可以在运行时刻决定哪些候选者参与到链中。O b s e r v e r ( 5 . 7 )模式定义并保持对象间的依赖关系。典型的O b s e r v e r的例子是Smalltalk 中的模型/视图/控制器，其中一旦模型的状态发生变化，模型的所有视图都会得到通知。其他的行为对象模式常将行为封装在一个对象中并将请求指派给它。S t r a t e g y ( 5 . 9 )模式将算法封装在对象中，这样可以方便地指定和改变一个对象所使用的算法。C o m m a n d ( 5 . 2 )模式将请求封装在对象中，这样它就可作为参数来传递，也可以被存储在历史列表里，或者以其他方式使用。S t a t e ( 5 . 8 )模式封装一个对象的状态，使得当这个对象的状态对象变化时，该对象可改变它的行为。Vi s i t o r ( 5 . 11 )封装分布于多个类之间的行为，而I t e r a t o r ( 5 . 4 )则抽象了访问和遍历一个集合中的对象的方式。5.1 CHAIN OF RESPONSIBILITY(职责链)—对象行为型模式1. 意图使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。2. 动机考虑一个图形用户界面中的上下文有关的帮助机制。用户在界面的任一部分上点击就可以得到帮助信息，所提供的帮助依赖于点击的是界面的哪一部分以及其上下文。例如，对话框中的按钮的帮助信息就可能和主窗口中类似的按钮不同。如果对那一部分界面没有特定的帮助信息，那么帮助系统应该显示一个关于当前上下文的较一般的帮助信息—比如说，整个对话框。因此很自然地，应根据普遍性( g e n e r a l i t y )即从最特殊到最普遍的顺序来组织帮助信息。而且，很明显，在这些用户界面对象中会有一个对象来处理帮助请求;至于是哪一个对象则取决于上下文以及可用的帮助具体到何种程度。这儿的问题是提交帮助请求的对象(如按钮)并不明确知道谁是最终提供帮助的对象。我们要有一种办法将提交帮助请求的对象与可能提供帮助信息的对象解耦( d e c o u p l e )。Chain of R e s p o n s i b i l i t y模式告诉我们应该怎么做。这一模式的想法是，给多个对象处理一个请求的机会，从而解耦发送者和接受者。该请求沿对象链传递直至其中一个对象处理它，如下图所示。从第一个对象开始，链中收到请求的对象要么亲自处理它，要么转发给链中的下一个候选者。提交请求的对象并不明确地知道哪一个对象将会处理它—我们说该请求有一个隐式的接收者(implicit receiver)。假设用户在一个标有“P r i n t”的按钮窗口组件上单击帮助，而该按钮包含在一个P r i n t D i a l o g的实例中，该实例知道它所属的应用对象(见前面的对象框图)。下面的交互框图(diagram) 说明了帮助请求怎样沿链传递:在这个例子中，既不是aPrintButton 也不是aPrintDialog 处理该请求;它一直被传递给a n A p p l i c a t i o n，anApplication 处理它