设计模式例子归纳总结

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