《设计模式-工大》PPT课件.ppt

哈尔滨工业大学计算机学院唐好选,软件设计模式,主要内容,软件设计模式基础创建型模式结构型模式行为型模式,广义讲，软件设计模式是可解决一类软件问题并能重复使用的软件设计方案狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题的解决方案模式体现的是程序整体的构思，所以有时候它也会出现在分析或者是概要设计阶段 模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来,什么是设计模式,模式名称(Pattern Name)问题(Problem)：描述应该在何时使用模式。解释了设计问题和问题存在的前因后果,可能还描述模式必须满足的先决条件解决方案(Solution)：描述了设计的组成成分、相互关系及各自的职责和协作方式。模式就像一个模板，可应用于多种场合，所以解决方案并不描述一个具体的设计或实现，而是提供设计问题的抽象描述和解决问题所采用的元素组合（类和对象）效果(consequences)：描述模式的应用效果及使用模式应权衡的问题,模式的基本要素,模式名和分类意图：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？动机：说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景适用性：什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？如何识别这些情况？结构：采用对象建模技术对模式中的类进行图形描述,如何描述设计模式,参与者：指设计模式中的类 和/或 对象以及它们各自的职责协作：模式的参与者如何协作以实现其职责效果：模式如何支持其目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？实现：实现模式时需了解的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题代码示例：用来说明怎样实现该模式的代码片段相关模式：与这个模式紧密相关的模式有哪些？其不同之处是什么？这个模式应与哪些其他模式一起使用？,描述设计模式（续）,开-闭原则(Open Closed Principal)单一职责原则里氏代换原则依赖倒置原则接口隔离原则,设计模式的原则,设计模式就是实现了上述原则，从而达到代码复用、增加可维护性的目的,定义：软件对扩展是开放的，对修改是关闭的。开发一个软件时，应可以对其进行功能扩展(开放)，在进行扩展的时候，不需要对原来的程序进行修改(关闭)好处：在软件可用性上非常灵活。可以在软件完成后对软件进行扩展，加入新的功能。这样，软件就可通过不断的增加新模块满足不断变化的新需求由于不修改软件原来的模块，不用担心软件的稳定性,开闭原则（OCP）,实现的主要原则抽象原则：把系统的所有可能的行为抽象成一个底层；由于可从抽象层导出一个或多个具体类来改变系统行为，因此对于可变部分，系统设计对扩展是开放的可变性封装原则：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装,开闭原则（OCP）,就一个类而言，应该仅有一个引起它变化的原因每一个引起类变化的原因就是一个职责，当类具有多职责时,应把多余职责分离出去，分别创建一些类来完成每一个职责每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化举例 interface Modem public void dial(String pno);public void hangup();public send(char c);public char recv();Modem类有两个职责：连接管理和数据通信，应将它们分离,单一职责原则（SRP）,listKov替换原则（LSP）,定义：“继承必须确保超类所拥有的性质在子类中仍然成立”，当一个子类的实例能够替换任何其超类的实例时，它们之间才具有is-A关系里氏替换原则是继承复用的基石，只有当派生类可以替换掉其基类，而软件功能不受影响时，基类才能真正被复用，派生类也才能够在基类的基础上增加新的行为LSP本质：在同一个继承体系中的对象应该有共同的行为特征例子：企鹅是鸟吗？生物学：企鹅属于鸟类 LSP原则：企鹅不属于鸟类，因为企鹅不会“飞”违反LSP的后果：有可能需要修改客户代码,依赖倒置原则（DIP）,定义：高层模块不应依赖低层模块，二者都应该依赖于抽象高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略的实现高层抽象不依赖高层和低层模块的具体实现，最多只依赖于低层的抽象低层抽象和实现也只依赖于高层抽象 辅助原则 任何变量都不应该持有一个指向具体类的引用任何类都不应该从具体类派生任何方法都不应覆盖其任何基类中已经实现了的方法,接口隔离原则（ISP）,多个和客户相关的接口要好于一个通用接口如果一个类有几个使用者，与其让这个类载入所有使用者需要使用的所有方法，还不如为每个使用者创建一个特定接口，并让该类分别实现这些接口,在设计模式经典著作GOF95中，设计模式从应用的角度被分为三个大的类型 创建型模式/结构型模式/行为型模式根据模式的范围分，模式用于类还是用于对象类模式：处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了对象模式：处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性从某种意义上来说，几乎所有模式都使用继承机制，所以“类模式”只指那些集中于处理类间关系的模式，而大部分模式都属于对象模式的范畴,设计模式的类型,用来创建对象的模式，抽象了实例化过程 工厂模式：父类负责定义创建对象的公共接口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成抽象工厂模式：为一个产品族提供统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类单件（Singleton）模式：保证一个类有且仅有一个实例，提供一个全局访问点,创建型设计模式,创建型设计模式,生成器（Builder）模式：将复杂对象创建与表示分离，同样的创建过程可创建不同的表示。允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节原型（Prototype）模式：通过“复制”一个已经存在的实例来返回新的实例（不新建实例）。被复制的实例就是“原型”，这个原型是可定制的。原型模式多用于创建复杂的或者耗时的实例，因为这种情况下，复制一个已经存在的实例使程序运行更高效；或者创建值相等，只是命名不一样的同类数据,结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象来实现新的功能（对象结构型模式）组合（Composite）模式：定义一个接口，使之用于单一对象，也可以应用于多个单一对象组成的对象组装饰（Decorator）模式：给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能代理（Proxy）模式：在软件系统中，有些对象有时候由于跨越网络或者其他障碍，而不能够或者不想直接访问另一个对象，直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切，这就是代理（Proxy）模式,结构型设计模式,结构型设计模式,享元（Flyweight）模式：Flyweight是一个共享对象，它可以同时在不同上下文（Context）使用外观（Facade）模式：外观模式为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度，使子系统更易于使用和管理。外观承担了子系统中类交互的责任桥梁（Bridge）模式：桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题适配器(Adapter)模式：将一个类的接口适配成用户所期待的接口。一个适配器允许因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中,着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程模版（Template）模式：定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。子类在不改变算法架构的情况下，可重新定义算法中某些步骤观察者（Observer）模式：定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈迭代子（Iterator）模式：提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示,行为型设计模式,责任链（Chain of Responsibility）模式：很多对象由每一个对象对其下一个对象的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任备忘录（Memento）模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态命令（Command）模式：将请求及其参数封装成一个对象，作为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作,行为型设计模式,状态（State）模式：允许一个“对象”在其内部状态改变的时候改变其行为，即不同的状态，不同的行为访问者（Visitor）模式：表示一个作用于某对象结构中的各元素的操作。可以在不改变各元素的类的前提下定义作用于这些元素的新操作 解释器(Interpreter)模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子中介者（Mediator）模式：用一个中介对象来封装一系列的对象交互策略（Strategy）模式：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化,行为型设计模式,创建型设计模式,工厂模式抽象工厂模式建造者模式单件模式原型模式,创建型设计模式,在面向对象编程中,常用的方法是用new操作符构造对象实例，但在有些情况下，new操作符直接生成对象会带来一些问题（1）创建对象之前必须清楚所要创建对象的类信息，但个别情况下无法达到此要求，譬如打开一个视频文件需要一个播放器对象，但是用户可能不知道具体播放器叫什么名字，需要系统分派给这个视频文件一个合适的播放器，这种情况下用new运算符并不合适,工厂模式的由来,（2）许多类型对象的创造需要一系列步骤需要计算或取得对象的初始设置需要选择生成哪个子对象实例在生成需要对象之前必须先生成一些辅助功能对象在这些情况,新对象的建立就是一个“过程”，而不仅仅是一个操作。为了能方便地完成这些复杂的对象创建工作，可引入工厂模式,工厂模式的由来,工厂模式的结构,Product：定义工厂方法所创建对象的接口ConcreteProduct：实现Product接口Factory：声明工厂方法，返回一个Product类型对象。Factory也可以定义一个工厂方法的缺省实现，返回一个缺省ConcreteProduct对象Concrete Factory：重定义工厂方法，返回一个ConcreteProduct实例,工厂模式的参与者,一个日志管理器：设计日志记录类，支持记录的方法有FileLogEventLog,工厂模式实例分析,/LogFactory类publicabstractclassLogFactory publicabstractLogCreate();,工厂模式实例分析,/FileFactory类publicclassFileFactory:LogFactorypublicoverrideFileLogCreate()returnnewFileLog();,/EventFactory类publicclassEventFactory:LogFactorypublicoverrideEventLogCreate()returnnewEventLog();,publicclassApppublicstaticvoidMain(stringargs)LogFactoryfactory=newEventFactory();/FileFactoryfactory=newFileFactory();Loglog=factory.Create();log.Write();,工厂模式客户端程序,客户程序有效避免了具体产品对象和应用程序之间的耦合，增加了具体工厂对象和应用程序之间的耦合在类内部创建对象通常比直接创建对象更灵活工厂模式通过面向对象的手法，将具体对象的创建工作延迟到子类，提供了一种扩展策略，较好的解决了紧耦合问题,工厂模式实例分析,抽象工厂模式的由来,在软件系统中，经常面临“一系列相互依赖对象”的创建工作，由于需求变化，这“一系列相互依赖的对象”也要改变，如何应对这种变化呢？如何像工厂模式一样绕过常规的”new”，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？一种说法：可以将这些对象一个个通过工厂模式来创建。但是，既然是一系列相互依赖的对象，它们是有联系的，每个对象都这样解决，如何保证他们的联系呢？,实例：Windows桌面主题，当更换一个桌面主题的时候，系统的开始按钮、任务栏、菜单栏、工具栏等都变了，而且是一起变的，他们的色调都很一致，类似这样的问题如何解决呢？应用抽象工厂模式，是一种有效的解决途径,抽象工厂模式的由来,抽象工厂模式的意图,意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类适用场合一个系统独立于其产品创建、组合和表示时一个系统由多个产品系列中的一个来配置时强调一系列相关产品对象的设计以便进行联合时提供一个产品类库，只想显示其接口而非实现时,抽象工厂模式的结构,Abstract Factory：声明创建抽象产品对象的操作接口ConcreteFactory：实现创建具体对象的操作Abstract Product：为一类产品对象声明一个接口ConcreteProduct：定义一个被具体工厂创建的产品对象,抽象工厂模式的参与者,实例：需要设计一个花园布局 花园有三种风格：典雅型、实用型和懒人型 花园中有3个位置需要种植植物：花台、墙角和花园中心,抽象工厂模式的应用实例,建造者（Builder）模式的由来,在软件系统中，有时面临着“一个复杂对象”的创建工作，该复杂对象通常由各个部分的子对象用一定的算法构成这个复杂对象的各个部分经常面临着剧烈变化，但是将它们组合在一起的算法却相对稳定如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？,建造者模式的意图和适用性,意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示适用性场合需要生成的产品对象有复杂的内部结构创建复杂对象的算法稳定，或建造者模式可以强迫生成一定的顺序当构造过程允许被构造的对象有不同的表示时,建造者模式的结构,建造者模式的参与者,Builder：为创建一个Product对象的各个部件指定抽象接口ConcreteBuilder：实现Builder接口来构造和装配产品各个部件，提供一个检索产品的接口Director：构造一个使用Builder接口的对象Product：表示被构造的复杂对象,实例：设计游戏场景中的房屋房屋由五个部分组成：地板、墙壁、窗户、门和天花板构建房屋的步骤固定，而具体组件（门、窗等）易变采用建造者模式分离易变组件和稳定的构建过程,建造者模式的应用示例,public abstract class House/定义一个房屋抽象类 public abstract class Builder/这一部分是易变的 public abstract void BuildFloor();/地板 public abstract void BuildDoor();/门 public abstract void BuildWindows();/窗户 public abstract void BuildWall();/墙壁 public abstract void BuildHouseCeiling()/天花板 public abstract House GetHouse();,建造者模式的应用示例,建造者模式的应用示例,public abstract class GameManager public static House CreateHouse(Builder builder)builder.BuildFloor();builder.BuildDoor();builder.Buildwall();builder.BuildWindows();builder.BuildHouseCeiling();return builder.GetHouse();,建造者模式的应用示例,public class RomanHouseBuilder:Builder public override void BuildDoor()public override void BuildFloor()public override void BuildWindows()public override void BuildWall()public override void BuildHouseCeiling()public override House GetHouse(),建造者模式的应用示例,class App public static void main()House house=GameManager.CreateHouse(new RomanHouseBuilder();,建造者模式分析,建造者模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节每一个Builder都相对独立，而与其它Builder无关可对构造过程更加精细控制将构建代码和表示代码分开建造者模式的缺点在于难于应付“分步骤构建算法”的需求变动,单件（Singleton）模式的由来,单件模式的实例较为普遍:系统中只能有一个窗口管理器系统中只能有一个文件系统一个数字滤波器只能有一个A/D转换器一个会计系统只能专用于一个公司,单件模式的由来,如何才能保证一个类只有一个实例并且这个实例易于被访问呢？一个全局变量使得一个对象可以被访问，但它不能防止你实例化多个对象一个更好的办法是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法,单件模式的意图和适用性,意图：保证一个类仅有一个实例,并提供一个全局访问点适用场合：当类只能有一个实例而且用户可以从一个众所周知的访问点访问它时当这个唯一实例是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展实例时,单件模式的结构,Singleton 被调用的单件对象定义一个Instance操作，允许客户访问它的唯一实例。Instance是一个类操作（一个静态成员函数）可能负责创建它自己的唯一实例,单件模式的应用示例,Class Singleton/单件模式的定义 public:static Singleton*Instance();/通过该成员函数访问单件 protected:Singleton();/构造函数为受保护型，直接实例化将出错 private:static Singleton*_instance;/指向本身唯一实例的指针;,单件模式的应用示例,Singleton*Singleton:_instance=0;/初始化类成员Singleton*Singleton:Instance()If(_instance=0)_instance=new Singleton;/如果成员变量为0，则唯/一实例化return _instance;,单件模式的效果分析,对唯一实例的受控访问：因为Singleton类封装唯一实例，所以它可以严格的控制客户怎样以及何时访问它缩小名空间：Singleton模式是对全局变量的一种改进。它避免了那些存储唯一实例的全局变量污染名空间允许对操作和表示的精化：Singleton类可以有子类，而且用这个扩展类的实例来配置一个应用是很容易的。可以用所需要的类的实例在运行时刻配置应用,原型（Prototype）模式的由来,在软件系统中，客户希望创建一个类对象（产品）时，可能有三种情况：知道产品具体型号(使用new运算符创建)不知道型号，知道特定的需求(使用工厂模式)不知道需求，但想要一个和已知对象相同的对象-使用原型模式,原型（Prototype）模式的意图和适用性,意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象适用性：在下列情况下，应当使用Prototype模式当一个系统应独立于其产品创建，构成和表示时当要实例化的类在运行时刻指定时为了避免创建一个与产品类层次平行的工厂类层次时,原型模式的结构,客户：客户端类向原型管理器提出创建对象请求抽象原型：它是对各种具体原型的抽象，通常由一个接口或抽象类实现具体原型：被复制的对象。此角色需要实现抽象的原型角色所要求的接口原型管理器：创建具体原型类的对象，记录每一个被创建的对象,原型模式的参与者,开发一个调色板，用户单击调色板上任一个方块，将会返回一个对应的颜色的实例很自然，我们利用OO的思想，把每一种颜色作为一个对象，并为他们抽象出一个公用的父类,原型模式应用示例,使用原型模式开发调色板的结构图,原型模式应用示例,Prototype模式的优点（1）对客户隐藏具体产品类，减少了客户知道的名字的数目（2）允许客户只通过注册原型实例就可以将一个具体产品类并入系统中，客户可以在运行时刻建立和删除原型（3）具有给一个应用软件动态加载新功能的能力。由于其独立性较高，可以很容易动态加载新功能而不影响老系统（4）产品类不需要非得有任何事先确定的等级结构，适用于任何的等级结构Prototype模式的缺点：Prototype模式的最主要缺点就是每个类必须配备一个克隆方法,原型模式的应用效果分析,工厂模式是一种极端情况下的抽象工厂模式，而抽象工厂模式可以看成是工厂模式的一种推广工厂模式的特点一个抽象产品类，可以派生出多个具体产品类一个抽象工厂类，可以派生出多个具体工厂类每个具体工厂类只能创建一个具体的长品类实例抽象工厂模式的特点多个抽象产品类，每个抽象产品类可以派生出多个具体产品类一个抽象工厂类，可以派生出多个具体工厂类每个具体工厂类可以创建多个具体产品类的实例,抽象工厂模式与工厂模式的区别,提供一个接口，用于创建相关和依赖对象的家族，而不需要明确指定具体类。抽象工厂允许客户使用抽象接口来创建一组相关产品，而不需要关心具体实际产出的产品是什么总结所有工厂都是用来封装对象的创建简单工厂，可以把客户程序从具体类解耦工厂方法使用继承，把对象创建委托给子类，子类实现工厂方法来创建对象抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中所有工厂模式都是通过减少应用程序与具体类之间的依赖关系促进松耦合工厂方法允许类将实例化延迟到子类进行抽象工厂创建相关的家族，而不需要依赖他们的具体类工厂帮助我们针对抽象编程，而不是针对具体类编程,抽象工厂模式与工厂模式的区别,工厂模式：定义一个创建对象的接口，由子类决定要实例化的具体类，工厂方法让类把实例化推迟到子类抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类建造者模式：封装一个产品（复杂对象）的构造过程，并允许按照步骤构造，向客户隐藏了产品的内部表现单件模式：确保一个类只有一个实例，并提供全局访问点原型模式：当创建给定类实例的过程很昂贵或很复杂时，使用原型模式，向客户隐藏制造新实例的复杂性,创建型设计模式总结,结构型设计模式,适配器模式外观模式装饰模式桥接模式享元模式代理模式组合模式,结构型模式的主要内容,适配器模式的由来,一个team要为外界提供S类服务，但team里面没有能够完成此项任务的member，只有team外的A可以完成这项服务。为保证对外服务类别的一致性（提供S服务）将A招安到team内，负责提供S类服务A不准备接受招安，可安排B去完成这项任务，并让B做好A的工作，让B工作的时候向A请教，此时，B是一个复合体（提供S服务，是A的继承弟子）将一个类的接口，转换成客户期望的另一个接口，适配器让原本接口不兼容的类可以一起工作,适配器模式使用过程,客户通过目标接口调用适配器的方法对适配器发出请求适配器使用被适配者接口把请求转换成被适配者的一个或者多个调用接口客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用,适配器模式的意图和适用性,意图：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作适用场合：使用一个已经存在的类，而它的接口不符合要求创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作使用一些已经存在的子类，但不可能通过子类化以匹配各自接口。对象适配器可以适配它的父类接口适配器模式分为类适配器和对象适配器,类适配器,用一个具体的Adapter类对Adaptee和Target进行匹配，Adapter类多重继承Adaptee和Target类Adapter可重定义Adaptee的部分行为，因为Adapter是Adaptee的一个子类,类适配器模式示例,/Target：定义Client使用的与特定领域相关的接口 public interface Target void request();,/Adaptee:现在需要适配的已经存在的接口 public class Adaptee public void specificRequest(),/Adapter:对Adaptee 的接口与Target接口进行适配 public class Adapter extends Adaptee implements Target public void request()super.specificRequest();,对象适配器,允许一个Adapter与多个Adaptee同时工作，即Adaptee本身以及它的所有子类（如果有子类的话）同时工作。Adapter可以一次给所有的Adaptee添加功能使用组合，不仅可以适配某个类，也可以适配该类的任何子类,对象适配器模式示例,/Target：定义Client使用的与特定领域相关的接口 public interface Target void request();,/Adaptee:现在需要适配的已经存在的接口 public class Adaptee public void specificRequest(),/Adapter:对Adaptee 的接口与Target接口进行适配 public class Adapter implements Target public Adapter(Adaptee adaptee)super();this.adaptee=adaptee;public void request()adaptee.specificRequest();private Adaptee adaptee;,适配器模式效果分析,优点方便设计者自由定义接口，不用担心匹配问题缺点属于静态结构，由于只能单继承，所以不适用于多种不同的源适配到同一个目标,外观（Facade）模式的由来,毕业生,教务处,公安处,后勤处,图书馆,饭卡,饭卡余额,借书证,借书证押金,身份证、学生证,派遣证,学生证,毕业证、学位证,外观（Facade）模式的由来,毕业生,毕业手续代办处,教务处,后勤处,图书馆,公安处,学生证 身份证 借书证 饭卡,毕业证 学位证 派遣证 饭卡余额 借书证押金,外观（Facade）模式的由来,外观（Facade）模式的意图和适用性,提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用解除客户程序与抽象类具体实现部分的依赖性，有利于移植和更改当需要构建层次结构的子系统时，使用Faade模式定义每层的入口点。如果子系统间相互依赖，他们只需通过Faade进行通讯外观模式的本质是让接口变得更简单,外观（Facade）模式的结构,外观（Facade）模式的参与者,Faade知道哪些子系统类负责处理请求将客户的请求代理给适当的子系统对象Subsystem Classes实现子系统的功能处理由Faade 对象指派的任务没有Faade的任何相关信息,外观（Facade）模式的效果分析,对客户端屏蔽子系统组件，减少客户端使用对象数目实现了子系统与客户之间松耦合的关系，使得子系统组件的变化不会影响到客户不限制客户应用子系统类,装饰（Decorator）模式的由来,动态给对象添加额外职责。比如：一幅画有没有画框都可以挂在墙上，画是被装饰者。在挂在墙上之前，画可以被蒙上玻璃，装到框子里，玻璃画框就是装饰不改变接口，但加入责任。Decorator提供了一种给类增加职责的方法，不是通过继承，而是通过组合实现的,装饰（Decorator）模式的意图和适用性,意图动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator 模式比生成子类更为灵活适用场合在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立扩展，每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况是因为类定义被隐藏，或类定义不能用于生成子类,装饰（Decorator）模式的结构,Component对象接口：可以给对象动态地添加职责ConcreteComponent具体对象Decorator维持一个指向Component对象的指针，并定义一个与Component接口一致的接口ConcreteDecorator向组件添加职责Decorator将请求转发给它的Component对象，并有可能在转发请求前后执行一些附加的动作,装饰（Decorator）模式的结构,装饰（Decorator）模式的评价,使用Decorator模式可以很容易地向对象添加职责。可以用添加和分离的方法，在运行时添加和删除职责使用Decorator模式可以很容易地重复添加一个特性，而两次继承则极容易出错避免在层次结构高层的类有太多的特征：可以从简单的部件组合出复杂的功能。具有低依赖性和低复杂性缺点：Decorator与Component不一样，使用装饰时不应该依赖对象标识；有许多小对象,桥接（Bridge）模式的由来,例子：相同模块的跨平台使用设计模块A和B希望模块A和B能应用在X操作系统上，让A和B继承X操作系统的接口希望模块A和B能应用在Y操作系统上，让A和B继承Y操作系统的接口，以此类推问题：模块A和B缺乏复用性解决：抽象出统一的操作系统类的接口连接模块A和B的平台无关接口，通过桥接两个抽象模块来消除模块间的继承耦合，提高复用性,扩展Window抽象使之用于不同种类的窗口或新的平台很不方便,继承机制使得客户代码与平台相关,桥接（Bridge）模式的由来,将Window抽象和它的实现部分分别放在独立的类层次结构中,针对窗口接口,针对平台的窗口实现,桥接（Bridge）模式的由来,桥接（Bridge）模式的意图和适用性,意图：桥接模式的作用就是将抽象部分与实现部分分离，使它可以独立的变化适用的情况不希望在抽象和它的实现部分之间有一个固定的绑定关系想对客户完全隐藏抽象的实现部分,桥接（Bridge）模式的结构,桥接（Bridge）模式的参与者,Abstraction定义抽象类的接口维护一个指向Implementor类型对象的指针RefinedAbstraction扩充由Abstraction定义的接口Implementor定义实现类的接口，不一定要与Abstraction的接口完全一致，甚至可以完全不同ConcreteImplementor实现Implementor接口并定义它的具体实现Abstraction将Client的请求转发给它的Implementor对象,桥接（Bridge）模式的效果分析,分离接口及其实现部分，抽象类的实现可以在运行时刻进行配置，一个对象甚至可以在运行时刻改变它的实现提高可扩充性：抽象与实现两部分可以单独扩充实现细节对客户透明，可以对客户隐藏实现细节,桥接（Bridge）模式的意义,脱耦是指将抽象和实现之间的耦合解脱开，或者说将他们之间的强关联改成若关联强关联是指在编译时期已经确定的，无法在运行时期动态改变的关联弱关联是可以动态确定并可在运行时刻动态改变的关联继承关系是强关联，聚合关系是弱关联，将两个角色之间的继承关系修改为聚合关系，就是将他们之间的强关联变换成弱关联。桥模式中的所谓脱耦就是指在一个软件系统的抽象和实现之间使用组合/聚合关系而不是继承关系，从而可以使两者可以相对独立的变化,享元（Flyweght）模式的由来,当大量使用同一种类型的实例（每个实例中包含部分相同的数据）,可能极大的耗费资源，使用Flyweight模式可以提高内存效率以CD唱片为例，每个CD有三个字段：出片日期、歌唱者姓名、唱片曲目姓名可能重复，可能有同一个演唱者的多个不同时期不同曲目的CD。歌唱者姓名可共享，其他字段均不可共享当你有几千张甚至更多CD时,Flyweight模式将节省更多空间,共享的flyweight越多,空间节省也就越大,享元（Flyweght）模式的意图和适用性,意图：避免大量拥有相同内容的小类的开销，使大家共享一个类(元类)适用性一个应用程序使用了大量的对象冗余使用了大量的对象，造成了很大的存储开销,享元（Flyweght）模式的结构,享元（Flyweght）模式的参与者,Flyweight：描述一个接口，可接受并作用于外部状态ConcreteFlyweight：实现Flyweight接口，并为内部状态增加存储空间。必须是可共享的，存储的状态必须是内部的UnsharedConcreteFlyweight：不强制共享FlyweightFactory：创建并管理flyweight对象；确保合理地共享flyweight，提供已创建的flyweight实例或者创建一个(如果不存在的话)Client：维持一个对flyweight的引用；计算或存储一个(多个)flyweight的外部状态,享元（Flyweght）模式的参与者,Flyweight执行时所需的状态必定是内部或外部的。内部状态存储在ConcreteFlyweight中，外部对象则由Client对象存储或计算。当用户调用flyweight对象操作时，将该状态传递给它用户不应直接对ConcreteFlyweight类进行实例化，而只能从FlyweightFactory对象得到ConcreteFlyweight对象，以保证对它们适当地进行共享,享元（Flyweght）模式的效果分析,Flyweight模式的核心就是把大量共享的对象收集在一起使用简单工厂模式进行管理，避免由于大量的小对象导致系统的内存过渡消耗当重复对象较多时，Flyweight模式具有较好的空间性能，但在查找搜索上消耗了时间复杂度,代理（Proxy）模式的由来,某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动如果对象是一个大图片,需要花费很长时间才能显示出来，此时需要做个图片Proxy来代替真正的图片如果对象在某远端服务器上,直接操作这个对象因为网络速度原因可能比较慢，那我们可以先用Proxy来代替那个对象如何应对这种变化？如何提供一种机制让原本交互起来比较困难的两个对象实现畅通无阻地交流呢？如何保持系统的结构不随着需求改变而轻易改变？这就是代理模式,代理（Proxy）模式的意图和适用性,意图：为其他对象提供一种代理以控制对这个对象的访问适用性：远程代理为一个对象在不同的地址空间提供局部代表虚代理在需要创建开销很大对象时缓存对象信息保护代理控制对原始对象的访问,代理（Proxy）模式的结构,代理（Proxy）模式的参与者,Proxy 保