JAVA面向对象与设计模式.ppt

JAVA,面向对象与设计模式董新军 2013.7.9,面向对象与设计模式,目 录面向对象UML几个概念设计模式,一、面向对象,1.1 为什么面向对象的编程会在软件开发领域造成如此震憾的影响？1.2 面向对象程序设计中的概念 1.3 多态性,1.1 为什么面向对象的编程会在软件开发领域造成如此震憾的影响？,面向对象编程（OOP）具有多方面的吸引力。对管理人员，它实现了更快和更廉价的开发与维护过程。对分析与设计人员，建模处理变得更加简单，能生成清晰、易于维护的设计方案。对程序员，对象模型显得如此高雅和浅显。此外，面向对象工具以及库的巨大威力使编程成为一项更使人愉悦的任务。每个人都可从中获益，至少表面如此。五大基本特征：(1)所有东西都是对象。可将对象想象成一种新型变量；它保存着数据，但可要求它对自身进行操作。(2)程序是一大堆对象的组合；通过消息传递，各对象知道自己该做些什么。(3)每个对象都有自己的存储空间，可容纳其他对象。或者说，通过封装现有对象，可制作出新型对象。(4)每个对象都有一种类型。根据语法，每个对象都是某个“类”的一个“实例”。(5)同一类所有对象都能接收相同的消息。这一特性称为对象的“可替换性”，是OOP最重要的概念之一。,1.2 面向对象程序设计中的概念,面向对象程序设计中的概念主要包括：对象、类、数据抽象、继承、动态绑定、数据封装、多态性、消息传递。通过这些概念面向对象的思想得到了具体的体现。1）对象（Object)可以对其做事情的一些东西。一个对象有状态、行为和标识三种属性。2）类（class)一个共享相同结构和行为的对象的集合。3）封装（encapsulation)：第一层意思：将数据和操作捆绑在一起，创造出一个新的类型的过程。第二层意思：将接口与实现分离的过程。4）继承 类之间的关系，在这种关系中，一个类共享了一个或多个其他类定义的结构和行为。继承描述了类之间的“是一种”关系。子类可以对基类的行为进行扩展、覆盖、重定义。5）组合 既是类之间的关系也是对象之间的关系。在这种关系中一个对象或者类包含了其他的对象和类。组合描述了“有”关系。6）多态 类型理论中的一个概念，一个名称可以表示很多不同类的对象，这些类和一个共同超类有关。因此，这个名称表示的任何对象可以以不同的方式响应一些共同的操作集合。7）动态绑定 也称动态类型，指的是一个对象或者表达式的类型直到运行时才确定。通常由编译器插入特殊代码来实现。与之对立的是静态类型。8）静态绑定 也称静态类型，指的是一个对象或者表达式的类型在编译时确定。9）消息传递 指的是一个对象调用了另一个对象的方法（或者称为成员函数）。10）方法 也称为成员函数，是指对象上的操作，作为类声明的一部分来定义。方法定义了可以对一个对象执行那些操作,1.3 多态性,指相同对象收到不同消息或不同对象收到相同消息时产生不同的实现动作。两种多态性：编译时多态性，运行时多态性。a、编译时多态性：通过重载函数实现。b、运行时多态性：通过重写覆盖实现。,二、UML几个概念,2.1 泛化关系（Generalization）2.2 关联关系（Association）2.3 依赖关系（Dependency）2.4 实现关系（Realization）,2.1 泛化关系（Generalization）,对于面向对象语言，UML中所说的泛化关系就是指类的继承关系。如果一个类是另一个类的子类，那么UML通过使用一个实线连接两个类的UML图来表示二者之间的继承关系，实线的起始端是子类的UML图，终点端是父类的UML图，但终点端使用一个空心的三角形表示实线的结束。,2.2 关联关系（Association）,如果A类中成员变量是用B类（接口）来声明的变量，那么A和B的关系是关联关系，称A关联于B。那么UML通过使用一个实线连A和B的UML图，实线的起始端是A的UML图，终点端是B的UML图，但终点端使用一个指向B的UML图的方向箭头表示实线的结束。,2.3 依赖关系（Dependency）,11/7/2023,10,如果A类中某个方法的参数用B类（接口）来声明的变量或某个方法返回的数据类型是B类型的，那么A和B的关系是依赖关系，称A依赖于B。那么UML通过使用一个虚线连A和B的UML图，虚线的起始端是A的UML图，终点端是B的UML图，但终点端使用一个指向B的UML图的方向箭头表示虚线的结束。,2.4 实现关系（Realization）,如果一个类实现了一个接口，那么类和接口的关系是实现关系，称类实现接口。UML通过使用虚线连接类和它所实现的接口，虚线起始端是类，虚线的终点端是它实现的接口，但终点端使用一个空心的三角形表示虚线的结束。,三、设计模式,设计模式分类：3.1创建型:与对象的创建有关3.2结构型:处理类或对象的组合3.3行为型:对类或对象怎样交互和怎样分配职责进行描述,Christopher Alexander说：“每一个设计模式描述一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次一次地使用该方案而不必做重复劳动。”-典型问题的经典解决方法！,设计模式分类,3.1.1 Factory method（工厂方法）-创建型模式,1.意图 定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。2.别名 虚构造器(Virtual Constructor)3.动机 框架使用抽象类定义和维护对象之间的关系。这些对象的创建通常也由框架负责。考虑这样一个应用框架,它可以向用户显示多个文档。在这个框架中,两个主要的抽象是类Application和Document。这两个类都是抽象的,客户必须通过它们的子类来做与具体应用相关的实现。例如,为创建一个绘图应用,我们定义类 DrawingApplication和DrawingDocument。A p p l i c a t i o n类负责管理 D o c u m e n t并根据需要创建它们 例如,当用户从菜单中选择 O p e n或New的时候。,3.1.1 Factory method：适用性及参与者,适用性：当一个类不知道它所必须创建的对象的类的时候。当一个类希望由它的子类来指定它所创建的对象的时候。当类将创建对象的职责委托给多个帮助子类中的某一个,并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。参与者：Product(Document)定义工厂方法所创建的对象的接口。ConcreteProduct(MyDocument)实现Product接口。Creator(Application)声明工厂方法,该方法返回一个 P r o d u c t类型的对象。C r e a to r也可以定义 一个工厂方 法的缺省实现,它返回一个缺省的 ConcreteProduct对象。可以调用工厂方法以创建一个 Product对象。ConcreteCreator(MyApplication)重定义工厂方法以返回一个 ConcreteProduct实 例。,3.1.1 Factory method模式的UML类图（1）,3.1.1 Factory method模式的UML类图（2）,3.1.2 Abstruct Factory（抽象工厂）,1.意 图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。2.动 机 考虑一个支持多种视感(l o o k-a n d-f e e l)标准的用户界面工具包。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准间的可移植性,一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。一个通俗的例子：请MM吃饭,麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西,虽然口味有所不同,但不管你带 MM 去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的 Factory。,3.1.2 Abstruct Factory:适用性与参与者,适用性：一个系统要独立于它的产品的创建、组合和表示时。一个系统要由多个产品系列中的一个来配置时。当你要强调一系列相关的产品对象的设计以便进行联合使用时。当你提供一个产品类库,而只想显示它们的接口而不是实现时。参与者：AbstractFactory 声明一个创建抽象产品对象的操作接口。ConcreteFactory 实现创建具体产品对象的操作。AbstractProduct 为一类产品对象声明一个接口。ConcreteProduct 定义一个将被相应的具体工厂创建的产品对象。实现AbstractProduct接口。,3.1.2 Abstruct Factory模式的UML类图,3.1.3 Builder（生成器）,1.意图 将一个复杂对象的构建与它的内部表示分离，使得同样的构建过程可以创建不同的表示。该模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节，可以强制实行一种分步骤进行的建造过程。2.动机 我们生活当中有许多设备都是以组装的形式存在的，例如台式电脑，那么有些厂商就会推出一些具有默认配置的组装电脑主机，顾客可以购买默认配置的产品，也可以要求厂商重新组装一部不同配置不同组装方式的主机。此时，我们就可以使用建造者模式来满足特殊顾客的要求了。注意到这个例子中厂商是重新组装一部主机，即关注点是主机的每个组成部分，这就符合上面Builder模式给出的使用场景了。,3.1.3 Builder（生成器）：适用性、参与者,在以下情况下使用Builder模式：1.当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式 时。2.当构造过程必须允许被构造的对象有不同表示时。参与者：1.Builder 为创建一个Product对象的各个部件指定抽象接口。提供一个检索产品的 接口。2.ConcreteBuilder 实现Builder的接口以构造和装配该产品的各个部件。定义并明确它所创建的表示。3.Director 构造一个使用Builder接口的对象。4.Product 表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。,3.1.3 Builder模式的UML类图,3.1.3生成器模式的优点,11/7/2023,24,生成器模式将对象的构造过程封装在具体生成器中，用户使用不同的具体生成器就可以得到该对象的不同表示。生成器模式将对象的构造过程从创建该对象的类中分离出来，使得用户无须了解该对象的具体组件。可以更加精细有效地控制对象的构造过程。生成器将对象的构造过程分解成若干步骤，这就使得程序可以更加精细，有效地控制整个对象的构造。生成器模式将对象的构造过程与创建该对象类解耦，使得对象的创建更加灵活有弹性。当增加新的具体生成器时，不必修改指挥者的代码，即该模式满足开-闭原则。,3.1.4 Prototype（原型）,1.意图 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。2.动机 当我们已经拥有某个得来不易的宝贝时，往往我们会很想再“变”一些出来，即这个宝贝的“复制品”，这种方式简单又理想，谁都想要学会这项本事。不可能的事情！不过，这种手段在软件设计中是完全可以实现的，在OO中的原型模式就是这样基于思想的。,3.1.4 Prototype（原型）：适用性与参与者,适用性：1.当一个系统应该独立于它的产品创建、构成和表示时。2.当要实例化的类是在运行时刻指定时，例如，通过动态装载。3.为了避免创建一个与产品类层次平行的工厂层次时。4.当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。参与者：1.Prototype 声明一个克隆自身的接口。2.ConcretePrototype 实现一个克隆自身的操作。3.Client 让一个原型克隆自身从而创建一个新的对象。,3.1.4 Prototype模式的UML类图,3.2.1 Adapter(适配器)类对象结构型模式,1.意图 将一个类的接口转换成客户希望的另外一个接口。A d a p t-e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。2.别名 包装器 Wrapper。,3.2.1 Adapter(适配器):适应性与参与者,以下情况使用Adapter模式 你想使用一个已经存在的类,而它的接口不符合你的需求。你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。(仅适用于对象 A d a p t e r)你想使用一些已经存在的子类,但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。参与者：Target 定义Client使用的与特定领域相关的接口。Client 与符合Target接口的对象协同。Adaptee 定义一个已经存在的接口,这个接口需要适配。Adapter 对Adaptee的接口与Ta rg e t接口进行适配。,07/07/13,30,3.2.1 Adapter模式的UML类图（对象适配器）,3.2.2 Decorator(装饰模式),1.意图 动态地给一个对象添加一些额外的职责。就增加功能来说,D e c o r a t o r模式相比生成子类更为灵活。2.别名 包装器Wrapper3.动机 有时我们希望给某个对象而不是整个类添加一些功能。例如,一个图形用户界面工具箱允许你对任意一个用户界面组件添加一些特性,例如边框,或是一些行为,例如窗口滚动。使用继承机制是添加功能的一种有效途径,从其他类继承过来的边框特性可以被多个子类的实例所使用。但这种方法不够灵活,因为边框的选择是静态的,用户不能控制对组件加边框的方式和时机。一种较为灵活的方式是将组件嵌入另一个对象中,由这个对象添加边框。我们称这个嵌入的对象为 装饰。这个装饰与它所装饰的组件接口一致,因此它对使用该组件的客户透明。它将客户请求转发给该组件,并且可能在转发前后执行一些额外的动作(例如画一个边框)。透明性使得你可以递归的嵌套多个装饰,从而可以添加任意多的功能。,3.2.2 Decorator(装饰模式)：适用性及参与者,以下情况使用Decorator模式 在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。处理那些可以撤消的职责。当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。参与者：Component 定义一个对象接口,可以给这些对象动态地添加职责。ConcreteComponent 定义一个对象,可以给这个对象添加一些职责。Decorator 维持一个指向Component对象的指针,并定义一个与 Component接口一致的接口。ConcreteDecorator 向组件添加职责。,07/07/13,33,3.2.2 Decorator装饰模式的UML类图,装饰性功能,3.2.3 Bridge(桥接模式),1.意图 将抽象部分与它的实现部分分离,使它们都可以独立地变化。2.别名 Handle/Body3.动机 通常方法的弊端：当一个抽象可能有多个实现时,通常用继承来协调它们。抽象类定义对该抽象的接口,而具体的子类则用不同方式加以实现。但是此方法有时不够灵活。继承机制将抽象部分与它的实现部分固定在一起,使得难以对抽象部分和实现部分独立地进行修改、扩充和重用。,3.2.3 Bridge：适用性及参与者,适用性：你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为,在程序运行时刻实现部分应可以被选择或者切换。类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时 B r i d g e模式使你可以对不同的抽象接口和实现部分进行组合,并分别对它们进行扩充。对一个抽象的实现部分的修改应对客户不产生影响,即客户的代码不必重新编译。参与者：Abstraction 定义抽象类的接口。维护一个指向Implementor类型对象的指针。RefinedAbstraction 扩充由Abstraction定义的接口。Implementor 定义实现类的接口,该接口不一定要与 A b s t r a c t i o n的接口完全一致;事实上这两个接口可以完全不同。一般来讲,I m p l e m e n t o r接口仅提供基本操作,而 A b s t r a c t i o n则定义了基于这些基本操作的较高层次的组合操作。ConcreteImplementor 实现Implementor接口并定义它的具体实现。,07/07/13,36,3.2.3 Bridge模式的UML类图,3.2.4 Proxy(代理模式),1.意图 为其他对象提供一种代理以控制对这个对象的访问。2.别名 Surrogate3.动机 对一个对象进行访问控制的一个原因是为了只有在我们确实需要这个对象时才对它进行创建和初始化。我们考虑一个可以在文档中嵌入图形对象的文档编辑器。有些图形对象(如大型光栅图像)的创建开销很大。但是打开文档必须很迅速,因此我们在打开文档时应避免一次性创建所有开销很大的对象。因为并非所有这些对象在文档中都同时可见,所以也没有必要同时创建这些对象。这一限制条件意味着,对于每一个开销很大的对象,应该根据需要进行创建,当一个图像变为可见时会产生这样的需要。但是在文档中我们用什么来代替这个图像呢?问题的解决方案是使用另一个对象,即图像 P r o x y,替代那个真正的图像。P r o x y可以代替一个图像对象,并且在需要时负责实例化这个图像对象。,3.2.4 Proxy：适用性和参与者,适用性：远 程 代 理(Remote Proxy)为 一 个 对 象在 不 同 的 地 址 空间 提 供 局 部 代 表。虚代理(Virtual Proxy)根据需要创建开销很大的对象。在动机一节描述的 ImageProxy就是这样一种代理的例子。保护代理(Protection Proxy)控制对原始对象的访问。保护代理用于对象应该有不同的访问权限的时候。智能指引(Smart Reference)取代了简单的指针,它在访问对象时执行一些附加操作。（C+智能指针：auto_ptr）参与者：Proxy 保存一个引用使得代理可以访问实体。Subject 定义RealSubject 和Proxy的共用接口,这样就在任何使用RealSubject的地方都可以使用Proxy。RealSubject 定义Proxy所代表的实体。,07/07/13,39,3.2.4 Proxy模式的UML类图,3.2.4 Proxy例子说明,以论坛中已注册用户和游客的权限不同来作为例子:已注册的用户拥有发帖,修改自己的注册信息,修改自己的帖子等功能;而游客只能看到别人发的帖子,没有其他权限。为了简化代码,更好的显示出代理模式的骨架,我们这里只实现发帖权限的控制。,3.2.5 Composite(组合模式),1.意图 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。2.动机 在绘图编辑器和图形捕捉系统这样的图形应用程序中,用户可以使用简单的组件创建复杂的图表。用户可以组合多个简单组件以形成一些较大的组件,这些组件又可以组合成更大的组件。一个简单的实现方法是为 Text和Line这样的图元定义一些类,另外定义一些类作为这些图元的容器类(Container)。然而这种方法存在一个问题:使用这些类的代码必须区别对待图元对象与容器对象,而实际上大多数情况下用户认为它们是一样的。对这些类区别使用,使得程序更加复杂。Composite模式描述了如何使用递归组合,使得用户不必对这些类进行区别。,3.2.5 Composite：适用性与参与者,适用性:你想表示对象的部分-整体层次结构。你希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。参与者:Component 为组合中的对象声明接口。在适当的情况下,实现所有类共有接口的缺省行为。声明一个接口用于访问和管理 Component的子组件。Leaf 在组合中表示叶节点对象,叶节点没有子节点。在组合中定义图元对象的行为。Composite 定义有子部件的那些部件的行为。存储子部件。在Component接口中实现与子部件有关的操作。Client 通过Component接口操纵组合部件的对象。,07/07/13,43,3.2.5 Composite模式的UML类图,3.3.1 Visitor(访问者模式),1.意图 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。2.动机 考虑一个编译器,它将源程序表示为一个抽象语法树。该编译器需在抽象语法树上实施某些操作以进行“静态语义”分析,例如检查是否所有的变量都已经被定义了。它也需要生成代码。因此它可能要定义许多操作以进行类型检查、代码优化、流程分析,检查变量是否在使用前被赋初值,等等。此外,还可使用抽象语法树进行优美格式打印、程序重构、code instrumentation以及对程序进行多种度量。这些操作大多要求对不同的节点进行不同的处理。例如对代表赋值语句的结点的处理就不同于对代表变量或算术表达式的结点的处理。因此有用于赋值语句的类,有用于变量访问的类,还有用于算术表达式的类,等等。这里的问题是,将所有这些操作分散到各种节点类中会导致整个系统难以理解、难以维护和修改。将类型检查代码与优美格式打印代码或流程分析代码放在一起,将产生混乱。此外,增加新的操作通常需要重新编译所有这些类。如果可以独立地增加新的操作,并且使这些节点类独立于作用于其上的操作,将会更好一些。,3.3.1 Visitor适用性与参与者,在下列情况下使用 Visitor模式:一个对象结构包含很多类对象,它们有不同的接口,而你想对这些对象实施一些依赖于其具体类的操作。需要对一个对象结构中的对象进行很多不同的并且不相关的操作,而你想避免让这些操作“污染”这些对象的类。Vi s i t o r使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时,用 Visitor模式让每个应用仅包含需要用到的操作。定义对象结构的类很少改变,但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口,这可能需要很大的代价。如果对象结构类经常改变,那么可能还是在这些类中定义这些操作较好。参与者：Visitor(访问者)ConcreteVisitor(具体访问者)Element(元素)ConcreteElement(具体元素),07/07/13,46,3.3.1 Visitor模式的UML类图,函数名可以重载：用一样的名称,3.3.2 Iterator(迭代器)对象行为型模式,1.意图 提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示。2.别名 游标(Cursor)。3.动机 一个聚合对象,如列表(list),应该提供一种方法来让别人可以访问它的元素,而又不需暴露它的内部结构.此外,针对不同的需要,可能要以不同的方式遍历这个列表。但是即使可以预见到所需的那些遍历操作,你可能也不希望列表的接口中充斥着各种不同遍历的操作。有时还可能需要在同一个表列上同时进行多个遍历。迭代器模式都可帮你解决所有这些问题。这一模式的关键思想是将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器(i t e r a t o r)对象中。迭代器类定义了一个访问该列表元素的接口。迭代器对象负责跟踪当前的元素;即,它知道哪些元素已经遍历过了。,3.3.2 Iterator(迭代器)：适用性与参与者,适用性:访问一个聚合对象的内容而无需暴露它的内部表示。支持对聚合对象的多种遍历。为遍历不同的聚合结构提供一个统一的接口(即,支持多态迭代)。参与者：Iterator(迭代器)迭代器定义访问和遍历元素的接口。ConcreteIterator(具体迭代器)具体迭代器实现迭代器接口。对该聚合遍历时跟踪当前位置。Aggregate(聚合)聚合定义创建相应迭代器对象的接口。ConcreteAggregate(具体聚合)具体聚合实现创建相应迭代器的接口,该操作返回 ConcreteIterator的一个适当的实例。,3.3.2 Iterator模式的UML类图,3.3.3 Observer(观察者)对象行为型模式,1.意图 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。举例：“半夜，猫大叫一声，主人被惊醒，老鼠四散而逃。”2.别名 依赖(Dependents),发布-订阅(Publish-Subscribe)3.动机 将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,因为这样降低了它们的可重用性。这一模式中的关键对象是目标(s u b j e c t)和观察者(o b s e r v e-r)。一个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生改变,所有的观察者都得到通知。作为对这个通知的响应,每个观察者都将查询目标以使其状态与目标的状态同步。,3.3.3 Observer(观察者)对象行为型模式,1.意图 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。举例：“半夜，猫大叫一声，主人被惊醒，老鼠四散而逃。”2.别名 依赖(Dependents),发布-订阅(Publish-Subscribe)3.动机 将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合,因为这样降低了它们的可重用性。这一模式中的关键对象是目标(s u b j e c t)和观察者(o b s e r v e-r)。一个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生改变,所有的观察者都得到通知。作为对这个通知的响应,每个观察者都将查询目标以使其状态与目标的状态同步。,3.3.3 Observer(观察者)：适用性与参与者,适用性：1当一个抽象模型有两个方面,其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。2当对一个对象的改变需要同时改变其它对象,而不知道具体有多少对象有待改变。3当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之,你不希望这些对象是紧密耦合的。参与者：Subject(目标)目标知道它的观察者。可以有任意多个观察者观察同一个目标。提供注册和删除观察者对象的接口。Observer(观察者)为那些在目标发生改变时需获得通知的对象定义一个更新接口。ConcreteSubject(具体目标)当它的状态发生改变时,向它的各个观察者发出通知。ConcreteObserver(具体观察者)维护一个指向ConcreteSubject对象的引用。存储有关状态,这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标的状态保持一致。,3.3.3 Observer模式的UML类图,3.3.4 Template method(模板方法)对象行为型模式,1.意图 定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Te m p l a t e M e t h o d使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。2.动机 考虑一个提供 A p p l i c a t i o n和D o c u m e n t类的应用框架。A p p l i c a t i o n类负责打开一个已有的以外部形式存储的文档,如一个文件。一旦一个文档中的信息从该文件中读出后,它就由一个Document对象表示。抽象的Application类在它的OpenDocument操作中定义了打开和读取一个文档的每一个主要步骤。它检查该文档是否能被打开,创建与应用相关的 D o c u m e n t对象,将它加到它入的文档集合中,并且从一个文件中读取该Document。我们称O p e n D o c u m e n t为一个 模板方法(template method)。一个模板方法用一些抽象的操作定义一个算法,而子类将重定义这些操作以提供具体的行为。,3.3.4 Template method：适用性和参与者,适用性:一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现。各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。即“重分解以一般化”，首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。控制子类扩展。模板方法只在特定点调用“Hook Method（钩子方法）”操作，这样就只允许在这些点进行扩展。参与者：AbstractClass(抽象类,如Application)定义抽象的 原语操作(primitive operation),具体的子类将重定义它们以实现一个算法。ConcreteClass(具体类,如MyApplication)实现原语操作以完成算法中与特定子类相关的步骤。,3.3.4 Template method模式的UML类图,3.3.5 Chain of responsibility(职责链)对象行为型模式,1.意图 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。2.动机 考虑一个图形用户界面中的上下文有关的帮助机制。用户在界面的任一部分上点击就可以得到帮助信息,所提供的帮助依赖于点击的是界面的哪一部分以及其上下文。例如,对话框中的按钮的帮助信息就可能和主窗口中类似的按钮不同。如果对那一部分界面没有特定的帮助信息,那么帮助系统应该显示一个关于当前上下文的较一般的帮助信息。,3.3.5 Chain of responsibility-适用性和参与者,适应性：有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定；在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；处理一个请求的对象集合应被动态指定。参与者：Handler(如HelpHandler)定义一个处理请求的接口。(可选)实现后继链。ConcreteHandler(如PrintButton和PrintDialog)处理它所负责的请求。可访问它的后继者。如果可处理该请求,就处理之;否则将该请求转发给它的后继者。,3.3.5 Chain of responsibility模式的UML类图,3.3.6 State(状态)对象行为型模式,1.意图 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。2.别名 状态对象(Objects for States)3.动机 考虑一个表示网络连接的类 T C P C o n n e c t i o n。一个 T C P C o n n e c t i o n对象的状态处于若干不同状态之一:连接已建立(E s t a b l i s h e d)、正在监听(L i s t e n i n g)、连接已关闭(C l o s e d)。当一个T C P C o n n e c t i o n对象收到其他对象的请求时,它根据自身的当前状态作出不同的反应。例如,一个O p e n请求的结果依赖于该连接是处于连接已关闭状态还是连接已建立状态。S t a t e模式描述了TCPConnection如何在每一种状态下表现出不同的行为。,3.3.6 State(状态)：适用性和参与者,适用性:一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。一个操作中含有庞大的多分支的条件语句,且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常,有多个操作包含这一相同的条件结构。S t a t e模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象,这一对象可以不依赖于其他对象而独立变化。参与者：Context(环境,如TCPConnection)定义客户感兴趣的接口。维护一个ConcreteState子类的实例,这个实例定义当前状态。State(状态,如TCPState)定义一个接口以封装与 Context的一个特定状态相关的行为。ConcreteState subclasses(具体状态子类)每一子类实现一个与 Context的一个状态相关的行为。,3.3.6 State模式的UML类图(1),3.3.6 State模式的UML类图(2),3.3.7 Mediator(中介者模式)对象行为型模式,1.意图 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。同事对象向一个中介者对象发送和接收请求。中介者在各同事间适当地转发请求以实现协作行为。2.动机 面向对象设计鼓励将行为分布到各个对象中。这种分布可能会导致对象间有许多连接。在最坏的情况下,每一个对象都知道其他所有对象。虽然将一个系统分割成许多对象通常可以增强可复用性,但是对象间相互连接的激增又会降低其可复用性。大量的相互连接使得一个对象似乎不太可能在没有其他对象的支持下工作 系统表现为一个不可分割的整体。而且,对系统的行为进行任何较大的改动都十分困难,因为行为被分布在许多对象中。例如,考虑一个图形用户界面中对话框的实现。对话框使用一个窗口来展现一系列的窗口组件,如按钮、菜单和输入域等。通常对话框中的窗口组件间存在依赖关系。例如,当一个特定的输入域为空时,某个按钮不能使用;在称为列表框的一列选项中选择一个表目可能会改变一个输入域的内容。中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再相互显式引用。这些对象仅知道中介者,从而减少了相互连接的数目。,3.3.7 Mediator：适用性和参与者,适用性：一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。想定制一个分布在多个类中的行为,而又不想生成太多的子类。参与者：Mediator(中介者,如 DialogDirector)中介者定义一个接口用于与各同事(Colleague)对象通信。ConcreteMediator(具体中介者,如FontDialogDirector)具体中介者通过协调各同事对象实现协作行为。了解并维护它的各个同事。Colleague class(同事类,如 ListBox,EntryField)每一个同事类都知道它的中介者对象。每一个同事对象在需与其他的同事通信的时候,与它的中介者通信。,07/07/13,66,3.3.7 Mediator模式的UML类图,3.3.8 Facade模式,1.意图 也叫“外观模式”门面模式的根本动力在于，我们在设计中为了共用或者复用，底层的很多业务逻辑（可以看做是零件逻辑）并不单纯只是为了某个特定的应用，为了公用或者复用，显得碎化，再提供给外部使用的时候，就需要根据需要进行组装，为了减少用户对这个组装的依赖，往往提供一系列的组合接口（也就是门面接口）给外部使用。门面模式在实际生活中处处可见，组件化编程其实也源于这种思想。制造业中零件-组件-成品的制造过程也是这种思想的体现，而且提供了很大的灵活性。当然，为了支持这种设计模式，底层的零件逻辑或者是组件逻辑需要分割合理，接口要标准，而且在连接和事务处理方面也要考虑周详。门面模式没有相对固定的结构模式，但在