购买

¥30.0

加入VIP
  • 专属下载券
  • 上传内容扩展
  • 资料优先审核
  • 免费资料无限下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 23种设计模式PPT合集

23种设计模式PPT合集.ppt

23种设计模式PPT合集

烟雨梦兮
2018-10-11 0人阅读 举报 0 0 0 暂无简介

简介:本文档为《23种设计模式PPT合集ppt》,可适用于IT/计算机领域

、工厂方法模式主讲:田旭园程序:奚亮亮ppt:叶良波答问:陈才国页FACTORYMETHOD请MM去麦当劳吃汉堡不同的MM有不同的口味要每个都记住是一件烦人的事情我一般采用FactoryMethod模式带着MM到服务员那儿说"要一个汉堡"具体要什么样的汉堡呢让MM直接跟服务员说就行了。工厂方法模式:核心工厂类不再负责所有产品的创建而是将具体创建的工作交给子类去做成为一个抽象工厂角色仅负责给出具体工厂类必须实现的接口而不接触哪一个产品类应当被实例化这种细节。感谢王良芳大神在校内的分享新增种模式的形象比喻。缺:简单工厂模式、缺省适配模式和不变模式。创建模式:简单工厂、工厂方法、抽象工厂、单例、建造、模型结构模式:适配器、缺省适配、合成、装饰、代理、享元、门面、桥梁行为模式:不变、策略、模板方法、观察者、迭代子、责任链、命令备忘录、状态、访问者、解释器、调停者。(最后三种不讲)工厂方法模式是类的创建模式又叫虚拟构造子(VirtualConstructor)模式或者多态性工厂(PolymorphicFactory)模式。   工厂方法模式的用意是定义一个创建产品对象的工厂接口将实际工作推迟到子类中。工厂方法解决问题:工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性工厂方法模式保持了简单工厂模式的优点而且克服了它的缺点。工厂方法缩略图该模式的优点:   这种抽象的结果使这种工厂方法模式可以用来允许系统不修改具体工厂角色的情况下引进新产品这一特点无疑使得工厂模式具有超过简单工厂模式的优越性。在工厂方法模式中一般都有一个平行的等级结构也就是说工厂和产品是对应的的。抽象工厂对应抽象产品具体工厂对应具体产品。简单的示意图如下:各种角色分类   抽象工厂角色:具体工厂角色:抽象产品角色:具体产品角色:*、简单工厂模式主讲人:陈儒组员:韩政高、戴鹏军、陈群页*简单的介绍简单工厂模式是创建型模式用于对象的创建它不属于种gof设计模式。它是工厂模式家族中最简单实用的模式可以理解为是不同工厂模式的一个特殊实现。设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案是解决某个方向上的变动需求的问题。而工厂设计模式的存在是为了解决哪一方面的问题呢?或者说它的动机是什么呢?*动机在软件系统中经常面临着“某个对象”的创建工作由于需求的变化这个对象经常面临着剧烈的变化但是它却拥有比对象最终完成任务。对于大数据量的加载VirtualProxy模式可以让加载在后台进行前台用的Prxoy对象使得整体运行速度加快。虚代理例子在文档中嵌入图形对象的文档编辑器有些图形对象的创建开销很大。但是打开文档必须很迅速因此我们在打开文档时避免一次性创建所有开销很大的对象。意味着应该根据需要进行创建我们使用一个图像代理替代那个真的图像能够实现这个需求。保护代理控制对一个对象的访问权限。一般用于不同客户对对象拥有不同访问权限的时候。结构上保护代理和远程代理以及虚代理是极为相似的只是在请求访问真实对象时提供的功能不同。区别:远程代理向客户隐藏了远端机器或进程上的对象虚代理负责管理了真实对象的加载方式。而保护代理则为用户访问对象的权限进行管理、享元模式王萌(讲课)黄万德(PPT、代码)王勋(回答问题)页FLYWEIGHT每天跟MM发短信手指都累死了最近买了个新手机可以把一些常用的句子存在手机里要用的时候直接拿出来在前面加上MM的名字就可以发送了再不用一个字一个字敲了。共享的句子就是FlyweightMM的名字就是提取出来的外部特征根据上下文情况使用。享元模式:FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。*享元模式运用共享技术有效地支持大量细粒度的对象模式结构中的四种角色享元接口(Flyweight)具体享元(ConcreteFlyweight)享元工厂(FlyweightFactory)客户端(Client)类图享元模式的特点享元模式的意图是通过共享有效支持大量细粒度的对象来提供应用程序的性能节省系统中重复创建对象实例的性能消耗这个怎么理解呢?、当我们系统中某个对象类型的实例较多的情况。、并且要求这些实例进行分类后发现真正有区别的分类很少的情况。享元模式的使用场景 、当我们发现某个类型的对象有大量的实例时我们是否可以对这些实例进行分类经过分类后我们发现只有很少的类别的情况下。 、我们发现通过使用享元模式后能够提高系统的性能和不会带来更多的复杂度时。享元模式的优点使用享元可以节省内存的开销特别适合处理大量细粒度对象这些对象的许多属性值是相同的而且一旦创建则不容许修改享元模式中的享元可以使用方法的参数接受外部状态中的数据但外部状态数据不会干扰到享元中的内部数据这就使得享元可以在不同的环境中被共享、Façade(门面)模式主讲:汪庆锋组员:沈仙桥、阮金晶、毛泉涌页FACADE我有一个专业的Nikon相机我就喜欢自己手动调光圈、快门这样照出来的照片才专业但MM可不懂这些教了半天也不会。幸好相机有Facade设计模式把相机调整到自动档只要对准目标按快门就行了一切由相机自动调整这样MM也可以用这个相机给我拍张照片了。门面模式:外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口使得子系统更易于使用。每一个子系统只有一个门面类而且此门面类只有一个实例也就是说它是一个单例模式。但整个系统可以有多个门面类。Facade模式登场定义:将子系统中的各类(或结构与方法)整合成一个简明一致的界面隐藏子系统的复杂性使子系统更加容易使用。Facade模式登场(续)简单结构图FacadeClientClientClientsubsystemFacade模式登场(续)模式实现定义一个(或多个)具备所需接口的新类(门面类)新类(门面类)使用原有的系统客户使用门面类对象与原系统打交道模式剖析结合前面的Facade模式结构图来分析周星星看病这个实际例子:图中的subsystem对应了挂号、划价、缴费、取药这些操作集合Facade对应了接待员Receptionist对象然后Client对应了病人周星星。模式剖析(续)接待员Receptionist对象将子系统中的多个接口重新封装成一个更高层、更简单的接口供Client使用将子系统的复杂性隐藏起来将子系统与Client的联系解耦。用户不必关心子系统的运作方式只需和Facade也即Receptionist对象打交道完成自己所需的工序。模式优点它对客户屏蔽子系统组件因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。它实现了子系统与客户之间的松耦合关系而子系统内部的功能组件往往是紧耦合的。如果应用需要它并不限制用户使用子系统类因此你可以在系统易用性和通用性之间加以选择。模式适用场合当你要为一个复杂子系统提供一个简单接口时。客户只需要使用某个复杂系统的子集或者需要以一种特殊的方式与系统交互。希望封装或者隐藏原系统时。迪米特法则只与你直接的朋友们通信。迪米特法则要求一个对象的相互作用是短程的朋友的数目越少越好其实质是减少耦合度。Facade模式符合迪米特法则。模式的变体典型的门面模式强调不应该引入新的功能。门面模式的变体可以适当引入新的功能补充系统的原有功能。模式的原理Facade模式将类重新设计将原来分散的类结构及方法重新组合形成新的、统一的接口供上层应用使用。在某种意义上与Adapter及Proxy有类似之处。相关模式的异同点Proxy注重在为ClientSubject提供一个访问的中间层使应用程序无需去考虑平台及网络造成的差异及其它诸多技术细节。Adapter注重对接口的转换与调整。Facade所面对的往往是多个类或其它程序单元通过重新组合各类及程序单元对外提供统一的接口界面。、桥梁模式(BridgePattern)结构型模式 主讲:赵振钢小组成员:章国栋、郑书声、张勤锋页BRIDGE早上碰到MM要说早上好晚上碰到MM要说晚上好碰到MM穿了件新衣服要说你的衣服好漂亮哦碰到MM新做的发型要说你的头发好漂亮哦。不要问我"早上碰到MM新做了个发型怎么说"这种问题自己用BRIDGE组合一下不就行了桥梁模式:将抽象化与实现化脱耦使得二者可以独立的变化也就是说将他们之间的强关联变成弱关联也就是指在一个软件系统的抽象化和实现化之间使用组合聚合关系而不是继承关系从而使两者可以独立的变化。桥梁模式的定义和目的定义:将抽象和实现解耦使得两者可以独立地变化。桥梁模式中的所谓解耦就是指在一个软件系统的抽象化和实现化之间使用组合聚合关系而不是继承关系。将抽象部分与它的实现部分分离使它们都可以独立地变化。这就是桥梁模式的用意。桥梁模式的结构抽象化等级实现化等级结构与角色从上类图中可以看出这个系统含有两个等级结构也就是:由抽象化角色和修正抽象化角色组成的抽象化等级结构。由实现化角色和两个具体实现化角色所组成的实现化等级结构。Abstraction抽象化角色抽象化给出的定义并保存一个对实现化对象的引用。RefinedAbstraction修正抽象化角色扩展抽象化角色改变和修正父类对抽象化的定义。Implementor实现化角色这个角色给出实现化角色的接口但不给出具体的实现。这个接口不一定和抽象化角色的接口定义相同实际上这两个接口可以非常不一样。ConcreateImplementor具体实现化角色这个角色给出实现化角色接口的具体实现。桥梁模式的特点抽象和实现分离在该模式下实现可以不受抽象的约束不用再绑定在一个固定的抽象层次上。优秀的扩充能力实现对细节透明客户不用关心细节的实现它已经由抽象层通过聚合关系完成了封装。适用性想避免抽象方法和其实现方法绑定在一起抽象接口和它的实现都需要扩展出子类以备使用对一个抽象的实现部分的修改应对客户不产生影响即客户的代码不必重新编译相关模式与适配器模式的区别:适配器模式的目的是要改变已有的接口让它们可以相容以使没有关系的两个类能在一起工作桥梁模式是分离抽象化和实现化使得两者的接口可以不同因此两个模式是向相反方向努力的桥梁模式小结在使用桥梁模式时主要考虑如何拆分抽象和实现。桥梁模式的意图还是对变化的封装尽量把可能变化的因素封装到最细、最小的逻辑单元中避免风险扩散。因此在进行系统设计时发现类的继承有N层时可以考虑使用桥梁模式。一个类的内部状态创建后在整个生命期间都不朽就是不变类。这种使用不变类的做法叫做不变模式。、不变模式(Immutablepattern)演讲丁豪队员狄钦伍永超吴岩页优缺点优点在于允许任何多的对象共享不需要在多线程访问的时候进行同步。缺点在于一旦要修改不变对象只有重新创建一个新的实例。需要频繁修改的对象不能使用不变模式。享元模式中的享元对象多为不变类。弱不变模式定义一个类的实例的状态是不可变化的但是这个类的引用的实例具有可能会变化的状态。这样的类符合弱不变模式的定义。缺点一个弱不变对象引用的实例变量可以是可变对象可能会通过外界修改父对象的状态这是一个显著的缺点。可以在初始化可变对象时先进行clone。弱不变模式满足条件对象没有任何方法会修改对象的状态当对象的构造函数对对象的状态初始化之后对象的状态便不再改变。 所有的属性都应当是私有的以防客户端对象直接修改任何的内部状态。 这个对象所引用的对象如果是可变对象的话必须设法限制外界对这个对象的访问以防止对这些对象的修改。如果可能应该尽量在不变对象的内部来初始化。强不变模式定义一个类的实例的状态不会改变同时它的子类的实例也具有不可变化的状态。这样的类符合强不变模式。满足条件 所考虑的类所有的方法都应当是final这样这个类的子类不能够置换掉此类的方法。 这个类本身就是final的那么这个类就不可能会有子类从而也就不可能有被子类修改的问题。总结不变模式的核心就是对象不变从而引伸出对象复用共享的思想。如无状态的单例模式享元模式及原型模式都可以认为是不变模式的应用。其它如线程池缓存等的实现也一定程度上是使用不变模式。、策略模式讲课:翟斌斌PPT:张永振、朱辰答疑:叶志对象行为型模式页STRATEGY跟不同类型的MM约会要用不同的策略有的请电影比较好有的则去吃小吃效果不错有的去海边浪漫最合适单目的都是为了得到MM的芳心我的追MM锦囊中有好多Strategy哦。策略模式:策略模式针对一组算法将每一个算法封装到具有共同接口的独立的类中从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类各种算法在具体的策略类中提供。由于算法和环境独立开来算法的增减修改都不会影响到环境和客户端。*创建模式:对类的实例化过程的抽象化结构模式:如何将类或者对象结合在一起形成更大的结构。行为模式:在不同的对象之间划分责任和算法的抽象化。类模式:通过继承定义描述类之间关系编译时建立(模板工厂方法适配器解释器)对象模式:利用组合(聚合)定义来描述对象之间的关系。运行时建立。更加动态。什么是策略模式策略模式是对算法的包装是把使用算法的责任和算法本身分割开委派给不同的对象管理。策略模式通常把一个系统的算法包装到一系列的策略类里面作为一个抽象策略类的子类。策略模式的用意在于把可选的策略或方案封装在不同的类中并在这些类中实现一个共同的操作。策略模式简略类图策略模式的实现步骤、定义抽象角色类定义好各个实现的共同抽象方法、定义具体策略类具体实现父类的共同方法、定义环境角色类私有化申明抽象角色变量重载构造方法执行抽象方法。*经常见到的是所有的具体策略类都有一些公有的行为。这时候就应当把这些公有的行为放到共同的抽象策略角色Strategy类里面。策略模式在每一个时刻都只能使用一个策略对象但有的时候一个应用程序同时与几个策略对象相联系。换言之在应用程序启动时所有的策略对象就已经被创立出来而应用程序可以在几个策略对象之间调换。这只有在策略对象不会耗费很多内存的情况下才可行只有在策略对象的初始化会花费很长时间的情况下才需要。策略模式的结构策略模式的类图:这其中涉及到三个角色:环境(Context)角色:持有一个Strategy类的引用。抽象策略(Strategy)角色:这是一个抽象角色通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。具体策略(ConcreteStrategy)角色:包装了相关的算法或行为。使用场合如果一系统里面有许多类它们之间的区别仅在于它们的行为那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。一个系统需要动态地在几种算法中选择一种。那么这些算法可以包装到一个个的具体算法类里面而这些具体算法类都是一个抽象算法类的子类。一个系统的算法使用的数据不可以让客户端知道。策略模式可以避免让客户端涉及到不必要接触到的复杂的和只与算法有关的数据。如果一个对象有很多种行为如果不用恰当的模式这些行为就只有使用多重的条件选择语句。策略模式的优点()策略模式提供了管理相关的算法族的方法。定义了一系列算法使这些算法可以相互替换自由切换。()策略模式提供了可以替换继承关系的方法。()使用策略模式可以避免使用多重条件转移语句。()更好的扩展性策略模式的缺点()所有的策略模式都需要对外暴露客户端必须知道所有的策略类并自行决定使用哪一个策略类。()策略模式造成很多的策略类()只适合扁平的算法结构不适合于处理同时嵌套多于一个算法的情形。工厂方法模式门面模式装饰模式享元模式*策略模式仅仅封装算法提供新算法插入到已有系统中并不负责决定何时使用何种具体策略角色。换言之应当由客户羰自己决定在什么情况下使用什么具体策略角色。例如图书折扣问题中什么图书应当使用什么折扣算法方案并不是策略模式所能解决的这应由客户端决定。一些列的算法地位是平等是可以相互替换的构成了扁平的算法结构例如折上折折后返券等业务的实现。。图书折扣问题中添加算法四:在所有的折扣算法计算后总的折扣不能超过元。这意味着客户端必须首先使用折扣算法一、二、三计算出折扣总值后再使用算法四。利用工厂方法的内部记录所创建的产品实例并循环使用这些实例策略模式与其他模式的关系与建造者(Builder)模式的关系二者结构上相似。事实上建造模式是策略模式的一种特殊情况。这两种模式之间的区别是它们用意不同。建造者模式中核心功能是一步一步的方式创立一个产品它的Director角色一遍一遍调用建造者对象来把零件增加到产品上最后返还整个产品对象。策略模式Strategy角色在Context角色的调用下不仅可以提供新对象的创立还可以提供任何一种服务。与享元(FlyweightPattern)的关系如果有多个客户端对象需要调用同样的一些策略类的话就可以使它们实现享元模式这样客户端可以共享这些策略类。可组合使用。*封装产品的生产过程在子类中实现不同的内部表象但按步骤构造。与适合器(Adapter)模式的关系左边是类的适配器模式右边是对象的适配器模式二者在结构上相似。它们的区别在于它们的用意不同。适配器模式的用意是允许一个客户对象通过调用一个配备着完全不同的接口的对象来完成它原来所要做的功能。策略模式的用意是使用统一的接口为客户端提供不同的算法。与装饰(Decorator)模式的关系装饰模式类图装饰模式的用意在于不改变接口的情况下增强一个对象的功能。策略模式在保持接口不变的情况下使具体算法可以互换。策略模式只能处理客户端从几个具体算法中选择一个的情形而不能处理客户端同时选用一种一上算法的情形。为处理后者可以组合使用。*装饰模式将一个东西的表皮换掉而保持它的内心。Component类轻策略模式是保持借口不变的情况下使具体算法可以互换。抽象策略类重与桥梁(Bridge)模式的关系两种模式结构图比较策略模式是一个行为模式旨在封装一系列的行为(自由切换算法)桥梁模式则是解决在不破坏封装的情况下如何抽取出它的抽象部分和实现部分(独立扩展)*两个桥墩。与模板方法(Template)模式的关系模板方法模式与策略模式的不同在于策略模式使用委派的方法提供不同的算法行为而模板方法模式使用继承的方法提供不同的算法行为。可以组合使用模板方法重在封装算法骨架策略模式重在分离并封装算法的实现。与状态(State)模式的关系策略模式封装不同的算法算法之间没有交互以达到算法自由切换。状态模式封装不同的状态以达到状态切换导致行为发生改变的目的。*模板方法模式是由建造模式过度过来的。建造模式退化失去导演者角色后THEBESTFORYOU、模板方法模式演讲人:范则森成员:胡辰朱希欢计算机学院页TEMPLATEMETHOD看过《如何说服女生上床》这部经典文章吗?女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Templatemethod)但每个步骤针对不同的情况都有不一样的做法这就要看你随机应变啦(具体实现)模板方法模式:模板方法模式准备一个抽象类将部分逻辑以具体方法以及具体构造子的形式实现然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架而将逻辑的细节留给具体的子类去实现。模板方法的意图目标市场项目优势模板方法模式是在一个方法中定义一个算法的骨架而将一些步骤延迟到子类中实现。模板方法使得子类可以在不改变算法结构的情况下重新定义算法中的某些步骤换句话说就是一个算法的某些部分已经有完善的定义可以在基类中实现而其他部分会有几种实现形式最好留给派生类去实现认识模板方法模式这个模式是用来创建一个算法的模板。什么是模板?模板就是一个方法。更具体地说这个方法将算法定义成一组步骤其中的任何步骤都可以是抽象的有子类负责实现。这可以确保算法的结构保持不变同时由子类提供部分实现。这里涉及到两个角色:抽象模板类与具体模板类认识模板方法模式⑴抽象模板类:①定义了一个或多个抽象操作以便让子类实现。这些抽象操作叫做基本操作它们是一个顶级逻辑的组成步骤②定义并实现了一个模板方法⑵具体模板类:①实现父类所定义的一个或多个抽象方法②每一个抽象模板累都可以有任意多个具体模板类与之对应而每一个具体模板类都可以给出这些抽象方法的不同实现从而使得顶级逻辑的实现各不相同模板方法模式中的方法模板方法中的方法可以分为两大类:模板方法和基本方法模板方法:一个模板方法是定义在抽象类中的把基本操作方法组合在一起形成一个总算法或一个总行为的方法。一个抽象类可以有任意多个模板方法而不限于一个。每一个模板方法都可以调用任意多个具体方法。模板方法模式中的方法基本方法抽象方法:有抽象类声明由具体子类实现java语言中以abstract关键字标出来具体方法:由抽象类声明并实现而子类并不实现或置换java中没有abstract关键字钩子方法:有抽象类声明并实现而子类会加以扩展。通常抽象类给出的实现是一个空实现作为方法的默认实现。因此钩子的存在可以让子类有能力对算法的不同点进行挂钩要不要挂钩有子类自行决定模板方法模式模板方法模式采用了继承的方式来实现步骤的重用在某些面向对象的理论中通常认为使用将接口实现和对象相聚合的方式来实现功能的重用会比继承好但是这也要看实际情况在可以使用模板方法模式解决问题中使用继承是很好的解决方案。模板方法的设计分类:抽象模板角色里提供完整的方法它完成了所有派生类都要用到的一些基本功能抽象模板角色里只提供空方法把部分留给派生类去实现抽象模板角色里只包含某些操作的默认实现派生类里可以重新定义这些方法的实现抽象模板角色里的模板方法它是一个调用抽象方法、钩子方法以及具体方法的各种组合模板方法的优缺点优点:①模板方法模式把不变的行为转移到超类中以去除子类中重复的代码从而提供了很好的代码复用平台使用模板方法是系统扩展性得到增强最小化了变化对系统的影响缺点:会增加很多具体方法的数量如果选用的实现方式不当复用情况会很差应用范围:子类具有统一的操作步骤或操作过程子类具有不同的操作细节存在多个具有同样操作步骤的应用场景但某些具体的操作细节却各不相同与其他模式的关系与策略模式相比模板方法模式的中心放在了方法调用的顺序上策略模式的中心集中在方法的封装上。模板方法模式的子类不需要改变一个算法的结构就可以改变一个算法的特定步骤。模板方法模式经常会调用工厂方法模式来生成需要的对象模板方法模式的总结在实际应用中应充分发挥此模式的复用能力对于多个子类都可以使用的方法可以在抽象类中创建一个默认的实现这样可以减少其编程复杂度。模板方法模式的实现思想是由父类完全控制子类的逻辑子类可以实现父类的可变部分但要继承父类的逻辑且不能改变业务逻辑。、TheObserverPattern(观察者模式)主讲:赵洁琼成员:葛照君、黄珊珊、朱萍页OBSERVER想知道咱们公司最新MM情报吗?加入公司的MM情报邮件组就行了tom负责搜集情报他发现的新情报不用一个一个通知我们直接发布给邮件组我们作为订阅者(观察者)就可以及时收到情报啦观察者模式:观察者模式定义了一种一队多的依赖关系让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时会通知所有观察者对象使他们能够自动更新自己。设计原则将变化部分与固定不变的部分相分离。对该原则的另一种理解是:将变化的部分拿出来进行封装以便以后你可以修改它而不会影响那些不变的部分。这一原则几乎是所有设计模式的基础所有设计模式都提供了这样一种机制:让系统的某些部分独立于其他部分变化。对接口编程而不是对实现编程。观察者模式的定义观察者模式定义了对象间的一对多依赖关系。当一方的对象改变状态时所有的依赖者都会被通知并自动被更新。在观察者模式中被依赖的一方叫做目标或主题(Subject),依赖方叫做观察者(Observers)。观察者模式的基本类图根据主题状态的变化更新自身的状态对所有的观察者对象ooupdate()设置获得状态数据Observer模式参与者Subject(主题)知道它的观察者(观察者必须实现了一定的接口)可以有任意多个观察者。提供注册和注销观察者的接口Observer(观察者)为那些在主题发生变化时需要获得通知的对象定义一个更新(update)接口。ConcreteSubject(具体主题)保持实际状态数据当状态发生变化时通知各观察者ConcreteObserver(具体观察者)维持一个指向具体主题对象的引用存储有关状态实现Observer的更新接口使自身状态与主题状态保持一致高质量设计的原则松耦合(looseCoupling)如果两个对象是松耦合的则他们可以相互作用但彼此的依赖性很小。观察者模式符合松耦合的原则。因为:主题(subject)只需要知道其观察者(Observer)实现了某个接口。可以随时加入观察者。不需要修改主题就可以加入新的类型的观察者主题和观察者都可以独立地被复用修改主题或观察者都不会影响另一方。观察者之间互不相干。观察者模式的优点观察者模式在被观察者和观察者之间建立一个抽象的耦合。被观察者角色所知道的只是一个具体观察者聚集每一个具体观察者都符合一个抽象观察者的接口。被观察者并不认识任何一个具体的观察者它只知道都有一个共同的接口。由于被观察者和观察者没有紧密地耦合在一起因此它们可以属于不同的抽象化层次。如果被观察者和观察者都被扔在一起那么这个对象必然跨越抽象化和具体化层次观察者模式支持广播通信。被观察者会向所有的登记过的观察者发出通知。观察者模式的缺点如果一个被观察者对象有很多直接和间接的观察者的话将所有的观察者都通知到会花费很多时间如果在被观察者之间有循环依赖的话被观察者会触发它们之间进行循环调用导致系统崩溃。如果对观察者的通知是通过另外的线程进行异步投递的话系统必须保证投递是以自恰的方式进行的。虽然观察者模式可以随时的使观察者知道所观察的对象发生的变化但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化的。总结:Observer模式意图定义对象间的一种一对多的依赖关系。当一方的对象改变状态时所有的依赖者都会得到通知并被自动更新。别名依赖(Dependents)发布订阅(PublishSubscribe)总结:Observer模式动机将一个系统分割成一系列相互协作的类有一个常见的副作用:需要维护相关对象间的一致性。我们不希望为了维持一致性而使得各个类紧密耦合导致可重用性的降低。观察者模式使得任意数目的观察者不必知道彼此的存在且主题发生变化时都可以得到主题的通知而同步改变状态。是一种很松的耦合具有很好的可重用性。总结:Observer模式适用性当一个抽象模型有两个方面其中一个方面依赖于另一个方面时将这两者封装在独立的对象中使他们可以独立的改变和复用。当一个对象的改变需要同时改变其他对象而不知道具体有多少对象需要改变。当一个对象必须通知其他对象而他又不能假定其它对象是谁。、迭代子模式(IteratorPattern)叶钱炜、孙国道、夏佳佳、陈旻昊页ITERATOR我爱上了Mary不顾一切的向她求婚。Mary:"想要我跟你结婚得答应我的条件"我:"什么条件我都答应你说吧"Mary:"我看上了那个一克拉的钻石"我:"我买我买还有吗?"Mary:"我看上了湖边的那栋别墅"我:"我买我买还有吗?"Mary:"我看上那辆法拉利跑车"我脑袋嗡的一声坐在椅子上一咬牙:"我买我买还有吗?"迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。什么是迭代子模式?提供一种方法顺序访问一个聚合对象中的各个元素而又不暴露其内部表示。迭代子模式依赖于一个迭代器接口有了这个接口后就可以为各种对象集合(数组、列表、散列表)实现迭代器。于是客户可以直接使用这个迭代器访问这些集合而不需要关心迭代器是如何遍历这些集合的。判断是否在集合中有更多的元素返回集合中的下一个元素问题的类关系图迭代子模式由以下角色组成:)迭代器角色(Iterator):迭代器角色负责定义访问和遍历元素的接口。例子中的迭代器接口Iterator。  )具体迭代器角色(ConcreteIterator):具体迭代器角色要实现迭代器接口并要记录遍历中的当前位置。例子中的DinerMenuIterator和PancakeHouseIterator。  )容器角色(Container):容器角色负责提供创建具体迭代器角色的接口。  )具体容器角色(ConcreteContainer):具体容器角色实现创建具体迭代器角色的接口这个具体迭代器角色于该容器的结构相关。例子中的DinerMenu和PancakeHouse提供的CreateIterator()接口。一个迭代子模式类图客户通过容器角色提供的接口获得Iterator的接口。具体容器负责创建的具体的Iterator接口由具体的Iterator完成实际的遍历工作迭代子模式的优点迭代器让我们能游走于聚合内的每个元素而不暴露其内部表示。使用户能以统一的方法访问聚类中的每一个对象不管这个聚类中的元素是由数组或者ArraryList(或者其他)组成的。把遍历的任务交迭代器而不交给聚类不仅让聚类的接口变得简洁也能使聚类能更专注于它应该专注的事情上、责任链模式主讲:毛飞飞成员:刘明超陆新龙、李征页CHAINOFRESPONSIBLEITY晚上去上英语课为了好开溜坐到了最后一排哇前面坐了好几个漂亮的MM哎找张纸条写上"Hi,可以做我的女朋友吗?如果不愿意请向前传"纸条就一个接一个的传上去了糟糕传到第一排的MM把纸条传给老师了听说是个老处女呀快跑!责任链模式:在责任链模式中很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。*责任链模式概述责任链模式是使用多个对象处理用户请求的成熟模式责任链模式的关键是将用户的请求分派给许多对象这些对象被组织成一个责任链即每个对象含有后继对象的引用并要求责任链上的每个对象如果能处理用户的请求就做出处理不能处理就必须将用户的请求传递给责任链上的下一个对象。责任链模式的结构责任链模式是一种对象的行为模式它所涉及到的角色如下:第一、抽象处理者(Handler)角色定义出一个处理请求的接口如果需要接口可以定义出一个方法以返回对下家的引用。下图给出了一个示意性的类图:第二、具体处理者(ConcreteHandler)角色、处理接到请求后可以选择将请求处理掉或者将请求传给下家。下图给出了一个示意性的类图。责任链模式的静态类结构纯的与不纯的责任链模式一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个:一是承担责任二是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又把责任向下传的情况。在一个纯的责任链模式里面一个请求必须被某一个处理者对象所接受在一个不纯的责任链模式里面一个请求可以最终不被任何接受端对象所接受。纯的责任链模式的实际例子很难找到一般看到的例子均是不纯的责任链模式的实现。下面的情况下使用责任链模式第一、系统已经有一个由处理者对象组成的链。这个链可能由复合模式给出第一、当有多于一个的处理者对象会处理一个请求而且在事先并不知道到底由哪一个处理者对象处理一个请求。这个处理者对象是动态确定的。第二、当系统想发出一个请求给多个处理者对象中的某一个但是不明显指定是哪一个处理者对象会处理此请求。第三、当处理一个请求的处理者对象集合需要动态地指定时。责任链模式与其它模式的关系复合模式(CompositePattern)当责任链模式中的对象链属于一个较大的结构时这个较大的结构可能符合复合模式。命令模式(CommandPattern)责任链模式使一个特定的请求接收对象对请求或命令的执行变得不确定。而命令模式使得一个特定的对象对一个命令的执行变得明显和确定。模版方法模式(TemplateMethod)当组成责任链的处理者对象是按照复合模式组成一个较大的结构的责成部分的话模版方法模式经常用来组织单个的对象的行为。使用责任链模式的长处责任链模式减低了发出命令的对象和处理命令的对象之间的耦合它允许多与一个的处理者对象根据自己的逻辑来决定哪一个处理者最终处理这个命令。换言之发出命令的对象只是把命令传给链结构的起始者而不需要知道到底是链上的哪一个节点处理了这个命令。显然这意味着在处理命令上允许系统有更多的灵活性。哪一个对象最终处理一个命令可以因为由那些对象参加责任链、以及这些对象在责任链上的位置不同而有所不同。使用责任链模式的不足责任链模式可能会带来一些额外的性能损耗因为它要从链子开头开始遍历。、命令模式(CommandPattern)一种行为型模式钱国红、袁锋、何丽慧页COMMAND俺有一个MM家里管得特别严没法见面只好借助于她弟弟在我们俩之间传送信息她对我有什么指示就写一张纸条让她弟弟带给我。这不她弟弟又传送过来一个COMMAND为了感谢他我请他吃了碗杂酱面哪知道他说:"我同时给我姐姐三个男朋友送COMMAND就数你最小气才请我吃面。"命令模式:命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来使得请求的一方不必知道接收请求的一方的接口更不必知道请求是怎么被接收以及操作是否执行何时被执行以及是怎么被执行的。系统支持命令的撤消。命令模式的定义命令模式将“请求”封装成对象以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持撤销操作。核心:实现了请求调用者和请求接收者之间的解耦。命令模式的定义创建命令设置其接收者。持有一个命令对象并在某个时间点调用命令对象的execute()方法将请求付诸实行。接收者知道如何进行必要的操作实现这个请求。任何类都可以当接收者。调用接收者的动作以满足请求。为所有命令申明了一个接口。调用命令对象的execute()方法就可以让接收者进行相关的动作。这个接口也具备一个undo()方法。定义了动作和接收者之间的绑定关系。调用者只要调用execute()就可以发出请求然后用它调用接收者的一个或多个动作。命令模式的适用场合.使用命令模式作为“CallBack”在面向对象系统中的替代。.需要在不同的时间指定请求、将请求排队。.系统需要支持命令的撤消(undo)。.如果一个系统要将系统中所有的数据更新到日志里以便在系统崩溃时可以根据日志里读回所有的数据更新命令重新调用Execute()方法一条一条执行这些命令从而恢复系统在崩溃前所做的数据更新。一个系统需要支持交易。命令模式的优缺点优点:命令模式把请求一个操作的对象和知道怎么执行一个操作的对象分割开。命令类和其他任何别的类一样可以修改和推广。可以把命令对象聚合在一起合成为合成命令。由于增加新的具体命令类不影响其他的类因此增加新的具体命令类很容易。缺点:适用命令模式会导致某些系统有过多的具体命令类。命令模式总结耦合与变化:   耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系实体对象与行为操作之间也存在耦合关系。动机(Motivate):   在软件系统中“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合比如要对行为进行“记录、撤销重做、事务”等处理这种无法抵御变化的紧耦合是不合适的。意图(Intent):   将一个请求封装为一个对象从而使你可用不同的请求对客户进行参数化对请求排队或记录请求日志以及支持可撤消的操作。      命令模式和其他模式的关系与合成模式的关系:合成模式可以应用的命令类的合成上从几个具体命令类合成宏命令类。合成模式的简略类图如下所示:命令模式和其他模式的关系与备忘录模式的关系:如果命令需要撤销和恢复功能的话备忘录模式可以用来存储关于命令的效果状态信息以便在撤销命令时可以撤销命令的效果。备忘录模式的简略类图如下所示:命令模式和其他模式的关系与原始模型模式的关系:如果命令类带有clone()方法的话命令就可以被复制。原始模型模式的简略类图如下图所示:、备忘录(Memento)模式主讲人:何卡特组员:庞卫巍、邓宇乐页MEMENTO同时跟几个MM聊天时一定要记清楚刚才跟MM说了些什么话不然MM发现了会不高兴的哦幸亏我有个备忘录刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存这样可以随时察看以前的记录啦。备忘录模式:备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下将一个对象的状态捉住并外部化存储起来从而可以在将来合适的时候把这个对象还原到存储起来的状态。*备忘录模式又叫快照模式或Token模式是对象的行为模式GOF备忘录对象是一个用来存储另一个对象内部状态的快照的对象。它的用意是将一个对象的状态捕捉住并外部化存储起来。从而可以在将来合适的时候把这个对象还原到存储起来的状态。备忘录模式有两种实现方式:一种是白箱实现一种是黑箱实现。定义、白箱实现    备忘录角色的内部所存储的状态就对所有对象公开。因此这个实现叫白箱实现。    白箱实现将发起人角色的状态存储在一个大家看得到的地方因此是破坏封装性的。但是通过程序员的自律同样可以在一定程度上实现模式的大部分用意。因此白箱实现仍然是有意义的。白箱实现类图:备忘录模式的白箱实现涉及到三个角色:备忘录(Memento)角色:将发起人对象的内部状态存储起来。备忘录可以根据发起人对象的判断来决定存储多少发起人对象的内部状态。备忘录可以保护其内容不被发起人对象之外的任何对象所读取发起人(Originator)角色:创建一个含有当前的内部状态的备忘录对象。使用备忘录对象存储其内部状态负责人(Caretaker)角色:负责保存备忘录对象不检查备忘录对象的内容备忘录(Memento)角色白箱实现备忘录模式中使用的备忘录类可以被任意对象访问这就破坏了发起人状态的封装Memento类应该向Originator对象开放功能是对的因为如果不这样的话就无法保存发起人对象的状态但是Memento类不应该向Caretaker对象和其他类开放细节以避免所保存的状态被非法更改。因此这就牵扯到一个宽接口和窄接口的问题。白箱实现的问题所谓双重接口就是对某一个对象提供宽接口而对另一些对象提供窄接口。根据编程语言的性能双重接口的实现方式有所不同。具体到我们的备忘录模式需要解决的问题如下:宽接口和窄接口当然wide接口可以省略它所扮演的角色可以由Memento自己扮演:备忘录模式的黑箱实现    对于Java语言而言可以将备忘录角色(Memento)设置成发起人角色(Originator)的内部类从而将备忘录对象(Memento)封装在发起人角色(Originator)里在外部提供一个标识接口(MementoIF)给负责人(Caretaker)以及其它对象。这样发起人看到的是备忘录的所有接口而负责人及其它对象看到的仅仅是标识接口。使用内部类实现备忘录模式的简略类图:备忘录模式黑箱实现  在前面的两个实现中负责人角色所承担的责任并不包括操控发起人角色进行备忘录的创建和状态的恢复这两个责任是由客户端角色直接调用发起人角色和备忘录角色做到的。如果能让负责人角色调用备忘录角色和发起人角色进行备忘录创建和根据备忘录恢复发起人状态那么客户端便不再需要协调备忘录角色和发起人角色而只需要调用负责人角色即可。要做到这一点负责人角色就必须持有一个发起人角色的引用。负责人角色增强前面所给出的白箱和黑箱的示意性实现都是只存储一个状态的简单实现。常见的软件系统往往需要存储不只一个状态而是需要存储多个状态或者叫做多个检查点。发起人角色的状态存储在Vector对象中每个状态都有一个对应的索引号index多重检查点*备忘录模式与命令模式的关系:如果在某个系统中使用命令模式时需要实现命令的撤销功能那么命令模式可以使用备忘录模式来存储可撤销操作的状态。备忘录模式与原型模式的关系如果发起人角色支持原型模式的话备忘录模式可以使用原型模式进行备忘录的创建。备忘录模式与迭代子模式的关系当备忘录模式支持多个检查点时在各个检查点之间进行遍历需要使用迭代子模式。与其他模式的关系优点:使用备忘录模式来保存对象的历史状态可以有效地保持封装边界。简化了发起人(Originator)类。发起人不再需要管理和保存其内部状态的一个个版本客户端可以自行管理它们所需要的这些状态的版本。当发起人状态需要复原时可以使用存储起来的备忘录将状态恢复。缺点:如果备份的“备忘发起角色”存在大量的信息或者创建、恢复操作非常频繁则可能造成很大的开销。在实际编程中如果遇到要恢复状态的问题就考虑可以使用备忘录模式!!备忘录模式的优缺点、状态模式组员:刘向东金亦挺李侠君李邓邓陈强页STATE跟MM交往时一定要注意她的状态哦在不同的状态时她的行为会有不同比如你约她今天晚上去看电影对你没兴趣的MM就会说"有事情啦"对你不讨厌但还没喜欢上的MM就会说"好啊不过可以带上我同事么?"已经喜欢上你的MM就会说"几点钟?看完电影再去泡吧怎么样?"当然你看电影过程中表现良好的话也可以把MM的状态从不讨厌不喜欢变成喜欢哦。状态模式:状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时系统便改变所选的子类。什么是状态模式状态模式(StatePattern)又名状态对象模式(PatternofObjectsforStates)状态模式属于对象行为模式定义:当一个对象的内在状态改变时允许改变行为这个对象看上去就像是改变了它的类一样状态模式的结构用一句话来表述状态模式把所研究的对象的行为包装在不同的状态对象里每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候其行为也随之改变。状态模式的示意性类图如下图所示。结构中的参与角色抽象状态(State)角色:定义一个接口用以封装环境(Context)对象的一个特定的状态所对应的行为。具体状态(ConcreteState)角色:每一个具体状态类都实现了环境(Context)的一个状态所对应的行为。环境(Context)角色:定义客户端所感兴趣的接口并且保留一个具体状态类的实例。这个具体类的实例给出此环境对象的现有状态。用状态模式解决开始时的问题首先根据该问题设计相应的类图:pull():voidpush():voidpull():voidpush():voidBlueStatepull():voidpush():void……在什么情况下使用状态模式在以下两种情况下适合用状态模式一个对象的行为依赖于它所处的状态对象的行为必须随着其状态的改变而改变对象在某个方法里依赖于一重或多重的条件转移语句其中有大量的代码状态模式的实现状态模式在实现的时候要注意的地方:谁来定义状态的变化。状态对象的创立和湮灭。其中值得权衡的做法有两种:动态的创立所需要的状态对象不要创立不需要的状态对象。事先创立所有的对象然后不再湮它们。环境类可以把它自己作为参量传给状态对象。状态模式的效果状态模式需要对每一个系统可能取得的状态创立一个状态类(State)的子类。由于每一个状态都被包装到了类里面就可以不必采用过程性的处理方式以及过多的条件转移语句。使系统状态的变化变得很明显。可以在系统的不同部分使用相同的一些状态类的对象。缺点:会造成大量小的状态类优点:使程序免于大量的条件转移语句使系统更易于维护支持相应的原则如开闭原则等。状态模式的实质在使用状态模式前client需要介入改变状态而状态改变的实现是琐碎或复杂的使用状态模式之后client可以直接使用事件event来实现状态到最终行为的目的而根本不必关心该事件如何导致状态变化的这些是由状态机等内部来实现的。因此针对这种eventconditionstate作业状态模式封装了conditionstate部分。每个状态形成一个子类每个状态只关心它的下一个可能状态从而无形中形成了状态转换的规则。如果新的状态加入只涉及它的前一个状态修改和定义使得工程的维护以及扩展变得相对轻松。状态模式与策略模式的比较相同点:不论是状态模式还是策略模式都紧紧的遵守着开闭原则里氏代换原则和迪米特原则充分的面向接口编程利用封装特性不同点:策略模式主要考虑的是当我们要增加新的算法策略的时候如何能在最小代价下面实现增加(最典型的应用莫过于超市商场的打折算法)通过封装一系列平行且复杂多变的实现方式它为client提供了改变行为的接口但行为的改变是由client决定并实施的状态模式通过把对象的内在状态的变化封装起来提供给client相应的接口其目的在于要做到对象行为的变化对client来说是透明的********************)透明式:子结点集合的管理方法在抽象类或接口中定义向客户端隐藏树叶结点和树枝结点的区别。缺点:虽然树枝对象还是树叶对象在客户端看来是没区别了但是他们两者确实是有区别的。使用透明式的实现方式就会发生这样的情况:客户端可能调用了树叶对象的子结点管理方法使用透明式实现使得这样的错误在编译器无法被检查出来只能延迟到运行期才会暴露出来。(说白了就是客户端可能会调到空的方法。))安全式:子结点集合的管理方式只在树枝接点中定义客户端必须明确知道当前对象到底是树枝还是树叶。缺点:这种方式不够透明树枝和树叶具有不同的接口客户端就不能把它们当成同一类对象看待了。(说白了就是不能把树枝和树叶全部上转成他们的抽象类或接口。)***创建模式:对类的实例化过程的抽象化结构模式:如何将类或者对象结合在一起形成更大的结构。行为模式:在不同的对象之间划分责任和算法的抽象化。类模式:通过继承定义描述类之间关系编译时建立(模板工厂方法适配器解释器)对象模式:利用组合(聚合)定义来描述对象之间的关系。运行时建立。更加动态。*经常见到的是所有的具体策略类都有一些公有的行为。这时候就应当把这些公有的行为放到共同的抽象策略角色Strategy类里面。策略模式在每一个时刻都只能使用一个策略对象但有的时候一个应用程序同时与几个策略对象相联系。换言之在应用程序启动时所有的策略对象就已经被创立出来而应用程序可以在几个策略对象之间调换。这只有在策略对象不会耗费很多内存的情况下才可行只有在策略对象的初始化会花费很长时间的情况下才需要。*策略模式仅仅封装算法提供新算法插入到已有系统中并不负责决定何时使用何种具体策略角色。换言之应当由客户羰自己决定在什么情况下使用什么具体策略角色。例如图书折扣问题中什么图书应当使用什么折扣算法方案并不是策略模式所能解决的这应由客户端决定。一些列的算法地位是平等是可以相互替换的构成了扁平的算法结构例如折上折折后返券等业务的实现。。图书折扣问题中添加算法四:在所有的折扣算法计算后总的折扣不能超过元。这意味着客户端必须首先使用折扣算法一、二、三计算出折扣总值后再使用算法四。利用工厂方法的内部记录所创建的产品实例并循环使用这些实例*封装产品的生产过程在子类中实现不同的内部表象但按步骤构造。*装饰模式将一个东西的表皮换掉而保持它的内心。Component类轻策略模式是保持借口不变的情况下使具体算法可以互换。抽象策略类重*两个桥墩。*模板方法模式是由建造模式过度过来的。建造模式退化失去导演者角色后**

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

评分:

/220

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利