Menu
我公司是结合网络技术为家电维修行业服务最早,维修技术最专业的家电维修公司。公司总部设立在北京,各个省份均有我们的维修网点,从事20多年家电行业,值得您的信赖!

当前位置主页 > 模式 >

策画形式例子总结总结

日期:2019-11-26 18:26 来源: 模式

  29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 设计模式例子归纳总结 ————装饰模式 专业班级:信计080学号:0808060217 官方定义:动态地给一个对象增加其他职责。就扩展对象功能来说,装饰者模式比生成子类更为灵活。 装饰这模式利用组合在运行时动态的合成自己想要的对象,这比继承更具弹性。 利用继承设计子类的行为,是在编译时静态决定的,而且所有的子类都会继承到相同的行为,然而,如果 能够利用组合的做法扩展对象的行为,就可以在运行 时动态地进行扩展。.类应设计的对扩展开放,对修改 关闭。 1.装饰者和被装饰对象有相同的超类型。.可以用一个或多个装饰者包装一个对象。 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 后,加上自己的行为,以达到特定的目的。 4.对象可以在任何时候被装饰,所以可以在运行时动态的,不限量的用你喜欢的装饰者来装饰对象。 5.装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配,而不是获得其行为。 6.装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。在实际项目中可以根据需 要为装饰者添加新的行为,做到“半透明”装饰者。 7.适配器模式的用意是改变对象的接口而不一定改变对象的性能,而装饰模式的用意是保持接口并增加 对象的职责。 抽象构件角色:定义一个抽象接口,来规范准备附加功能的类。 具体构件角色:将要被附加功能的类,实现抽象构件角色接口。抽象装饰者角色:持有对具体构件角色 的引用并定义与抽象构件角色一致的接口。具体装饰 角色:实现抽象装饰者角色,负责为具体构件添加额 外功能。 其中,被装饰者与抽象装饰者都继承与抽象构件角色,具体装饰角色继承与抽象装饰角色,之所以让装 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 饰者和被装饰者继承于同一组件是想让装饰者和被装 饰者具有统一的类型而非为了继承行为。 装饰者模式的基本思想是用装饰者来包装组件使之成为一个同类型的新组件,所以在装饰者角色中,记 录当前对象,利用多态技术,用基类对象引用最终被 包裹后的对象,就获得了组件和所有包裹过组件的行 2.需要动态的给一个对象添加功能,这些功能可以再动态的撤销。 3.需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变的不现实。 4.当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产 生大量的子类,使得子类数目呈爆炸性增长。另一种 情况可能是因为类定义被隐藏,或类定义不能用于生 成子类。六、优缺点优点: 1.Decorator模式与继承关系的目的都是要扩展对象 的功能,但是 Decorator 可以提供比继承更多的灵活 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 2.通过使用不同的具体装饰类以及这些装饰类的排列组合,设计师可以创造出很多不同行为的组合。缺 1.这种比继承更加灵活机动的特性,也同时意味着更加多的复杂性。 2.装饰模式会导致设计中出现许多小类,如果过度使用,会使程序变得很复杂。.装饰模式是针对抽象组件 类型编程。但是,如果你要针对具体组件编程时,就 应该重新思考你的应用架构,以及装饰者是否合适。 当然也可以改变Component 接口,增加新的公开的行 为,实现“半透明”的装饰者模式。在实际项目中要做 出最佳选择。 制作一个可以给人搭配不同的服饰的系统,比如类似QQ,网络游戏或论坛都有的Avatar 系统.实现方式 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 刚开始学习设计模式的时候,感到这些模式真的非常抽象。今年下半年以来,随着我们组工作重点的转 移,以及我在小组中角色的变化,我开始有条件提出 自己对新系统的设计想法。在设计过程中,我发现了 很多设计模式的用处,也确实应用了很多设计模式, 这让我越来越感到设计模式的重要性,因此我写了这 十余篇专门介绍设计模式的文章,作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》中介 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 绍了一共23 种设计模式,我一共写了19 个设计模式, 余下四个,考虑到该模式的应用范围我就没有介绍。 在写这些文章时,其中的很多例子都是我在实践中提 炼出来的,当然也有很大一部分是《设计模式》中的 例子。不过,这四个人生活的年代里现在已经很远了, 所以它们的例子也很古老。让我们更加设计模式 设计模式是个好东西,它给出了很多设计中的技巧与思路,对于很多优秀的设计,它加以总结与提炼。 设计模式并非四人团拍脑瓜想出来的,而是他们搜集 了其他人优秀的设计,加以整理出来的,他们不是这 些模式的创造者,仅仅是整理者。 应用设计模式会给我们带来很多好处:软件将变得更加灵活,模块之间的耦合度将会降低,效率会提升, 开销会减少。更重要的,设计模式就好像美声唱法中 的花腔,让你的设计更加漂亮。总的来说,设计模式 似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了,在现在很多的图形界面框架都使用了 MVC 模式,大量跌代器模式的应 用,彻底改变了我们对集合的操作方式。不仅如此, 应用了设计模式的设计,往往被看成为优秀的设计。 这是因为,这些设计模式都是久经考验的。 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 在学习和使用设计模式的时候,往往出现一个非常严重的误区,那就是设计模式必须严格地遵守,不能 修改。但是设计模式不是设计模型,并非一成不变。 正相反,设计模式中最核心的要素并非设计的结构, 而是设计的思想。只有掌握住设计模式的核心思想, 才能正确、灵活的应用设计模式,否则再怎么使用设 计模式,也不过是生搬硬套。 当然,掌握设计模式的思想,关键是要仔细研究模式的意图和结构。一个模式的意图,就是使用这个设 计模式的目的,体现了为什么要使用这个模式,也就 是需求问题。这个模式的结构,就是如何去解决这个 问题,是一种手段、一种经典的解决方法,这种解决 方法只是一种建议。两个方面结合起来,明白为什么 需要设计模式,同时明白了如何实现这个模式,就容 易抓住模式的本质思想。 在抓住意图和结构的基础上,实践也是掌握设计模式的必要方法。当然,设计模式必须在某个场景下得 到应用才有意义,这也是为什么《设计模式》中提供 了大量的例子用来说明模式的应用场景,这实际上为 读者提供了一种上下文环境。学外语不是要强调“语言 环境”么,学习设计模式也是这样。 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 看到网上很多人在讨论设计模式,他们确实很有***,满嘴都是模式的名字,恨不得写个 HelloWorld 都要应用到设计模式。设计模式确实是好东西,但是, 中国有句古话叫作物极必反,即便是按照辩证法,事 物总要一分为二的看。 我们说设计模式的目的是为了让软件更加灵活,重用度更高。但是,某种意义上,设计模式增加了软件 维护的难度,特别是它增加了对象之间关联的复杂度。 我们总说,重用可以提高软件开发的效率。如果你是大牛,你自然希望你的设计可以被反复使用 10000 年,那就是:当世界毁灭的时候,你的设计依然存在。 然而,现实是一个系统的设计往往在5 年之内就会被 抛弃,这是因为:1,软件技术产生了新的变化,使用 新的技术进行的设计,无论如何都比你的设计好;2, 硬件环境发生了很大变化,你的设计里对开销或者效 率的追求已经没有意义了;3,新的大牛出现了,并且 取代了你的位置。 应用设计模式会导致设计周期的加长,但是很多项目还在设计阶段就已经胎死腹中,再好的设计也没有 发挥的余地。当我们向设计模式顶礼膜拜的时候,我 们还必须清醒地看到软件生产中非技术层面上的东西 往往具有决定性作用。 10 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 理想固然崇高,但现实总是残酷的。如何看清理想与现实的界限,恐怕是需要我们在实践中不断磨砺而 体会出来的。在看完设计模式后,不妨反问以下自己, 这些模式究竟能给你带来什么? Interpreter、Iterator、State模式 Interpreter模式:这个模式主要试图去解释一种语 言。如果你学过形式语言,那么这个模式对你来说是 多余的。 Iterator模式:这个模式试图隐藏集合的内部表示, 又同时可以使用户依次访问集合中的元素。现在 STL 和Java 的跌代器就是应用这个模式的结果。 State模式:这个模式的意图是允许对象在其状态改 变时修改其行为,好像对象改变了。这个模式的应用 场景是当对象的行为依赖于对象的状态时。为了实现 这个模式,我们可以为每个状态下的行为实现一个类, 当对象的状态发生改变,它调用不同状态对象的实例 方法。注意,以前可能需要使用switch 或者if 语句进 行分支转换,现在则利用多态机制完成。Flyweight 这个模式利用共享有效的支持大量的细粒度的对象。比如,编辑软件中,一篇文章有很多个字符,我 们可以对每个字符对象生成一个对象,如果这篇文章 11 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 有几M个文字,那么对象的数量肯定是不能容忍的。 使用 Flyweight 模式,我们将所有的文字对象共享起 来,文章中的字符仅仅是指向共享池中的某个对象的 索引。 在这里要搞清楚一件事情,利用Flyweight模式不会 有效地减少信息的数量,因为无论是否共享,表达这 么多信息所需要的编码数量是一定的,所以开销不会 大幅减小。只是,这个模式会减少系统中对象的数量, 因为大量的对象会被共享。在编辑软件中,字符对象 被共享,那么一篇文章中的文字,可以按照段落、格 式等等进行结组,一组文字构成一个对象,这样对象 从单个文字变成一组文字,数量大幅减少。在使用 Flyweight 模式需要注意的一点,由于对象被共享了, 因此这些对象没有各自的属性,那么根据上下文环境, 我们在使用这些对象的时候,必须向它传递一些参数。 在编辑软件中,这些参数可能就是字体、字号、颜色 等等信息。 使用Flyweight模式还有一个好处,那就是我们可以 在不修改系统的情况下增加享元。Command 模式 Command模式,将一个请求封装为一个对象。这样, 你可以向客户端发送不同请求的参数,排队或记录请 求,同时可以支持不能执行的请求。 12 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 在软件中,不同的模块、对象之间经常会各种调用,或者我们称之为请求。传统的方法,我们将请求实现 为函数调用。这样做是最简单的方法,但却在无形之 中增加了模块之间的耦合度。当请求发生很大变化的 时候,系统将变得很难维护。与此同时,当服务端增 加或者删除一个请求的时候,按照传统的方法,客户 端也必须重新编译,这样系统才能正确运行。 使用Command模式的一个核心思想就是,服务端提 供一个统一的请求处理接口,客户端则通过调用接口 向服务端发送请求,这些请求被封装成对象的形式。 在《设计模式》中,“四人团”并没有强调统一接口的 事情,它强调了另一个方面,那就是封装请求。事实 上,封装一个请求总是要求有一个地方来接受和处理 这个请求的,这个地方实际上就是统一请求接口。 象,这个对象保存着请求类型、参数等信息,服务端收到这个命令后就会执行Command 对象中的Execute 函数,这个函数具体实现了真正的操作。这种实现方 法可以保证增加新的请求而不必重新编译服务端。我 个人认为,Command 模式的另一个形式就是在服务端 实现各种操作,Command 对象只是负责指明请求的类 型,这样,当服务器端发现请求不正确时,可以忽略 13 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 该请求。和上一种形式相比,这种形式更加简洁,但 是缺少灵活性。 Command模式使得记录请求成为了可能,我们可以 捕获系统中的请求对象,记录他们。Composite 模式 Composite模式的意图是“将对象组合成树形结构表 示?整体-部分?的层次结构。Composite 使得用户对单 个对象和组合对象的使用更具有一致性”。 在Word中我们经常会将一些图元进行“组合”,组合 以后的图形还可以向简单图元那样进行移动、变形等 等操作;除此以外,在Word 中,我们对于一个字符、 一个词组、一句话、一个段落,甚至是整篇文章的操 作是相同的,我们都可以进行剪切、复制,进行字体 与大小的调整,进行颜色的变换。这些例子都是 Composite 模式的实例,我们将简单的元素组合成复 杂的元素,然后还可以像操作简单元素那样操作组合 元素。 Composite模式将子元素组织成树型,实际上,组织 成图型也没有问题。用户总是喜欢组合简单元素,一 方面,用户可以通过这样的组合来进行抽象,另一方 面,用户可以通过组合化简繁琐的操作。Composite 模式在各种可视化编辑软件中应用得最为广泛。 另一使用Composite的经典例子是Java 的Swing 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 统。所有的 Swing 组件都是继承自一个叫做 JComponent 的接口,因此,我们对一个 JFrame 作和对一个JButton的操作是一样的。这同时也使得, JFrame 在管理自己的子元素时,它不需要知道他们是 一个JButton 还是一个JPanel,对它来说,这只是一个 JComponent。 实现Composite 模式的关键是良好设计的接口,人 们应该对可能的元素进行分析,并设计出通用的操作。 尽可能的保证接口操作对所有元素都是有意义的,否 则就应该将那些只对部分元素有意义的操作下放到子 Proxy模式 按照“四人团”的说法,Proxy模式可以为控制另一个 对象而提供一个代理或者占位符。这个模式可以使我 们在真正需要的时候创建对象,如果我们不需要这个 对象,Proxy 模式会为我们提供一个占位符。如果我 们有大量这样消耗很大的对象的时候,我们就可以使 用Proxy 模式,初始情况下,Proxy 模式只会提供占位 符而不会真正创建对象,但是对于使用者来说,他看 到是真正的对象而不是一个代理。一旦使用者需要获 得或者更改对象属性的时候,Proxy 模式就会创建该 对象,在此之后,我们就可以通过代理访问线---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 Word里面应该是使用了 Proxy 模式。打开 一篇含图的很长的文档时,大部分的图片都不会被载 入,而仅仅是提供占位符,只有当用户准备察看这一 页的时候,代理才会真正载入图片。 Singleton模式一样,Proxy 模式都是保证我们可 以按需分配对象,不同的是,Singleton 模式还会保证 在全局范围内使用同一个对象实例,而 Proxy 则没有 这个功能。 Visitor模式 按照“四人团”的说法,Visitor模式的意图为:将元 素的操作表示成一种结构。这样Visitor 模式可以使你 在不修改元素结构的前提下增加新的操作。 考虑一个链表,我们需要一个求得最大元素的操作,这个操作可能是遍历每个节点,然后求的最大值。这 个时候我们又需要一个为每个元素加1 的操作,这个 操作还需要遍历每个节点,同时将每个元素加 之类似,还会有很多其他的针对元素操作,他们的特点都是要遍历链表。这个时候可以使用Visitor 模式, 结点类负责依次遍历,并调用Visitor 类中的函数,而 Visitor 类的具体实现则负责完成功能。 这里需要注意的是,Visitor类只能是一个接口,针 对不同的操作需要有不同的具体实现,针对不同的具 16 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 体元素,需要设计不同的操作。每个元素负责选择自 己应该调用的操作,Visitor 子类负责实现具体功能。 一个已知的应用是SmallTalk-80 的编译器,在编译 时,编译器需要建立一棵语法树。在这个时候,它使 用了Visitor 模式,针对不同的操作,比如:类型检查、 代码生成等操作实现不同的Visitor 具体类,Visitor 中针对不同的节点类型提供不同的操作接口,具体的节点负责选择调用哪种接口,这像是一种回调操作。 文档内容基本上来自于网上,并加上自己的理解而成。有的觉得网友总结得非常好,就完全照搬下来, 供学习之用。然而,有的摘抄并没有加上原链接和出 处,请谅解。 在设计比较设计模式的不同时,主要从以下几个方面思考: 2.各个设计模式之间并不是非此即彼的,他们之间有些有着很大的相似性。并且有的可以相互替代 3.UML图和实现时的细节区别 解释一:17 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 桥接模式在于分离了实现和抽象,它将其分别放到了两个不同的类层次. 说在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度 的变化”?如何利用面向对象的技术来使得该类型能 够轻松的沿着多个方向进行变化,而又不引入额外的 复杂度?这就要使用Bridge 模式。 从上图看到了两个变化维度,一个就是implementor,一个是 abstraction,前者是实现后者是抽象,那说明 实现和抽象两方面都可能变化。abstraction 可能派生 出不同的 RefinedAbstraction,而 Implementor 也有不 同的实际implementor. 那么这个 ConcreteImplemetorA之间是通过 Abstraction Implementor发生联系,而他们两个之间本身确实松散 的关系,而 Abstracion 聚合了几个 Implementor,那 Abstraction 即依赖了Implementor,而最终Abstraction 试图基于 implementor 提供的基本操作又定义了更高 层次的接口,比如Operation,它们使用了implemntor 提供的抽象接口,委托于具体来实现。而本身 18 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 abstracion 的高层接口也进行了派生。所以说有两个变 化维度。类似的策略者模式: 区别1:bridge为构造模式,strategy 为行为模式。 区别2:在策略模式中,并不考虑Context的变化, 只有算法的可替代性,而bridge 具有两个维度的变化。 Implementor接口仅提供基本操作,而 Abstraction则基于这些基本操作定义更高层次的操 作。而策略模式强调 Strategy 抽象接口的提供的是一 种算法,一般是无状态、无数据的,而 Context 桥接模式是结构型模式的一种,而策略模式则属于行为模式。以下是它们的UML 结构图。 在桥接模式中,Abstraction通过聚合的方式引用 Implementor。 在策略模式中,Context也使用聚合的方式引用 Startegy 抽象接口。 从他们的结构图可知,在这两种模式中,都存在一个对象使用聚合的方式引用另一个对象的抽象接口的 情况,而且该抽象接口的实现可以有多种并且可以替 换。可以说两者在表象上都是调用者与被调用者之间 19 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 的解耦,以及抽象接口与实现的分离。 1.首先,在形式上,两者还是有一定区别的,对比两幅结构图,我们可以发现,在桥接模式中不仅 Implementor 具有变化,而且 Abstraction 也可以发生 变化,而且两者的变化是完全独立的, ConcreateImplementior之间松 散耦合,它们仅仅通过 Abstraction与Implementor 之间的关系联系起来。而 在策略模式中,并不考虑 Context 的变化,只有算法 的可替代性。 2.其次在语意上,桥接模式强调Implementor接口仅 提供基本操作,而Abstraction 则基于这些基本操作定 义更高层次的操作。而策略模式强调 Strategy 抽象接 口的提供的是一种算法,一般是无状态、无数据的, 而Context 则简单调用这些算法完成其操作。 3.桥接模式中不仅定义Implementor的接口而且定义 Abstraction 的接口,Abstraction 的接口不仅仅是为了 Implementor通信而存在的,这也反映了结构型模 式的特点:通过继承、聚合的方式组合类和对象以形 成更大的结构。在策略模式中,Startegy Context的接口都是两者之间的协作接口,并不涉及 20 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 到其它的功能接口,所以它是行为模式的一种。行为 模式的主要特点就是处理的是对象之间的通信方式, 往往是通过引入中介者对象将通信双方解耦,在这里 实际上就是将Context 与实际的算法提供者解耦。 所以相对策略模式,桥接模式要表达的内容要更多,结构也更加复杂。桥接模式表达的主要意义其实是接 口隔离的原则,即把本质上并不内聚的两种体系区别 开来,使得它们可以松散的组合,而策略在解耦上还 仅仅是某一个算法的层次,没有到体系这一层次。 从结构图中可以看到,策略的结构是包容在桥接结构中的,桥接中必然存在着策略模式,Abstraction Implementor之间就可以认为是策略模式,但是桥接模 式一般 Implementor将提供一系列的成体系的操作,而且 Implementor 是具有状态和数据的静态结构。而且桥接 模式Abstraction 也可以独立变化 singleton限制了实例个数,有利于gc 的回收。 策略模式:策略模式针对一组算法,将每一个算法21 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 封装到具有共同接口的独立的类中,从而使得它们可 以相互替换。策略模式使得算法可以在不影响到客户 端的情况下发生变化。策略模式把行为和环境分开。 环境类负责维持和查询行为类,各种算法在具体的策 略类中提供。由于算法和环境独立开来,算法的增减, 修改都不会影响到环境和客户端。 使用QQ MM时使用外挂客户端:ME 抽象类: 外挂具体:策略图书销售算法 原型模式:通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建 出更多同类型的对象。原始模型模式允许动态的增加 或减少产品类,产品类不需要非得有任何事先确定的 等级结构,原始模型模式适用于任何的等级结构。缺 点是每一个类都必须配备一个克隆方法 复印技术:1不是同一个对象属同类 短消息1-n个MM 因为Java中的提供clone 方法来实现对象的克隆,所 Prototype模式实现一下子变得很简单.四:门面模 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 门面模式:外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接 口,使得子系统更易于使用,减少复杂性。每一个子 系统只有一个门面类,而且此门面类只有一个实例, 也就是说它是一个单例模式。但整个系统可以有多个 门面类。 Facade典型应用就是数据库JDBC 的应用和Session 的应用 Memento模式:Memento 对象是一个保存另外一个 对象内部状态拷贝的对象,这样以后就可以将该对象 恢复到原先保存的状态。模式的用意是在不破坏封装 的条件下,将一个对象的状态捕捉住,并外部化,存 储起来,从而可以在将来合适的时候把这个对象还原 到存储起来的状态。模式所涉及的角色有三个,备忘 录角色、发起人角色和负责人角色。 将发起人对象的内部状态存储起来,备忘录可以根据发起人对象的判断来决定存储多少发起人对象 23 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 备忘录可以保护其内容不被发起人对象之外的任何对象所读取。 相同点:在两种工厂模式在被使用的时候都能产生具体的产品类,比直接创建对象更加灵活!不同点: 工厂模式只有一个抽象产品类,而抽象工厂模式可以 有多个!工厂模式的具体工厂类只能创建一个具体类 的实例,而抽象工厂模式则可以创建多个! 不同点:抽象工厂模式是定义一个创建对象的接口,让子类决定实现哪一个类,抽象工厂使其子类延迟到 24 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 其子类,其本身是没有状态的。建造者模式是将一个 复杂对象的创建与他的表示分离,使同样的构造过程 可以创建不同的表示,其是有状态的,比抽象工厂更 加灵活! 对象适配器:不是通过继承的方式,而是通过对象组合的方式来进行处理的,我们只要学过 OO 的设计 原则的都知道,组合相比继承是推荐的方式。 类适配器:通过继承的方式来实现,将旧系统的方法进行封装。对象适配器在进行适配器之间的转换过 程中,无疑类适配器也能完成,但是依赖性会加大, 并且随着适配要求的灵活性,可能通过继承膨胀的难 以控制。 装饰模式是一个链型的组织关系,而组合模式是一个集合的组织关系,也就是说组合模式必须有一个类 是组合的容器,它包含了所有组合模式中的功能类, 而装饰模式任何一个类都是链上的一个节点而已。但 是这里装饰模式和组合模式没有优劣之分,只是适合 的场景不一样,模式本身就是没有优劣之分,只是各 自适合不同的场景。而在责任链模式里,很多对象由 25 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 每一个对象对其下家的引用而连接起来形成一条链。 请求在这个链上传递,直到链上的某一个对象决定处 理此请求。发出这个请求的客户端并不知道链上的哪 一个对象最终处理这个请求,这使系统可以在不影响 客户端的情况下动态的重新组织链和分配责任。 两者看上去都是某个类在不同条件下会有不同的行为表现。每个类的行为并非在自己本身上,而是寄托 给了条件类了。不过这个条件在状态模式中用 State 类表示,在访问者模式中用visitor 类表示。 状态模式中这些状态下的行为全部属于一个类,而访问者模式中每个条件下都会有不同类的行为;而且 状态模式中的每个具体的状态类中还可能包还对细小 状态的判断。 条件与需要此条件的类的接触方式不同,状态模式是将条件直接赋予需要的类,而访问者模式则是通过 objectStructure 来“访问”; 最重要的应该是两者的目的不同:状态模式是要更好的执行一个类不同状态下的行为,而访问者模式则 可以从 ObjectStructure 类中看出,它是一个结构固定 的类,但这个结构下的算法是变化的。 26 29---------------------------------------------感谢观看本文-------谢谢----------------------------------------------------------- [标签:标题] 2016 中介者模式解决的是对多个对象之间的通信问题,减少类之间的关联,外观模式解决的是子系统的接口 复杂度问题。中介者模式中对象可以向中介者请求, 外观模式中对象不会对外观有任何的协助请求。 这两个模式的相同之处在于它们可以使算法和上下文解耦,不同之处在于一个是使用继承来解决问题, 另一个是基于委托。模板方法准备一个抽象类,让它 定义了一个操作中算法的骨架,并可以实现部分逻辑, 然后声明一些抽象方法来迫使子类实现剩余的逻辑。 不同的子类可以以不同的方式实现这些抽象方法,从 而对剩余的逻辑有不同的实现。策略模式的用意是针 对一组算法,将每一个算法封装到具有相同接口的独 立的类中,从而使得它们可以相互替换。策略模式使 得算法可以在不影响到客户端的情况下发生变化。

模式

上一篇:

下一篇: