设计模式学习总结1.pdf

《设计模式学习总结1.pdf》由会员分享，可在线阅读，更多相关《设计模式学习总结1.pdf（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、.设计模式学习总结引子引子刚开场学习设计模式的时候，感到这些模式真的非常抽象。今年下半年以来，随着我们组工作重点的转移，以及我在小组中角色的变化，我开场有条件提出自己对新系统的设计想法。在设计过程中，我发现了很多设计模式的用处，也确实应用了很多设计模式，这让我越来越感到设计模式的重要性，因此我写了这十余篇专门介绍设计模式的文章，作为我的学习笔记。设计模式可复用的面向对象软件的根底有趣的是，梅宏一再在组会上强调应该译成重用 中介绍了一共 23 种设计模式，我一共写了 19 个设计模式 其中三个和在一篇文章中，余下四个，考虑到该模式的应用围我就没有介绍。在写这些文章时，其中的很多例子都是我在实践中

2、提炼出来的，当然也有很大一局部是设计模式中的例子。不过，这四个人四人团生活的年代里现在已经很远了，所以它们的例子也很古老。让我们更加设计模式让我们更加设计模式设计模式是个好东西，它给出了很多设计中的技巧与思路，对于很多优秀的设计，它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的，而是他们搜集了其他人优秀的设计，加以整理出来的，他们不是这些模式的创造者，仅仅是整理者。应用设计模式会给我们带来很多好处：软件将变得更加灵活，模块之间的耦合度将会降低，效率会提升，开销会减少。更重要的，设计模式就好似美声唱法中的花腔，让你的设计更加漂亮。总的来说，设计模式似乎将软件设计提升到艺术的层次。设计模式已经被

3、广泛的应用了，在现在很多的图形界面框架都使用了MVC 模式，大量跌代器模式的应用，彻底改变了我们对集合的操作方式。不仅如此，应用了设计模式的设计，往往被看成为优秀的设计。这是因为，这些设计模式都是久经考验的。模式不是模型模式不是模型在学习和使用设计模式的时候，往往出现一个非常严重的误区，那就是设计模式必须严格地遵守，不能修改。但是设计模式不是设计模型，并非一成不变。正相反，设计模式中最核心的要素并非设计的构造，而是设计的思想。只有掌握住设计模式的核心思想，才能正确、灵活的应用设计模式，否那么再怎么使用设计模式，也不过是生搬硬套。jz*.当然，掌握设计模式的思想，关键是要仔细研究模式的意图和构造

4、。一个模式的意图，就是使用这个设计模式的目的，表达了为什么要使用这个模式，也就是需求问题。这个模式的构造，就是如何去解决这个问题，是一种手段、一种经典的解决方法，这种解决方法只是一种建议。两个方面结合起来，明白为什么需要设计模式，同时明白了如何实现这个模式，就容易抓住模式的本质思想。在抓住意图和构造的根底上，实践也是掌握设计模式的必要方法。当然，设计模式必须在某个场景下得到应用才有意义，这也是为什么设计模式中提供了大量的例子用来说明模式的应用场景，这实际上为读者提供了一种上下文环境。学外语不是要强调“语言环境么，学习设计模式也是这样。不要设计模式不要设计模式看到网上很多人在讨论设计模式，他们确

5、实很有*，满嘴都是模式的名字，恨不得写个 HelloWorld 都要应用到设计模式。设计模式确实是好东西，但是，中国有句古话叫作物极必反，即便是按照辩证法，事物总要一分为二的看。我们说设计模式的目的是为了让软件更加灵活，重用度更高。但是，某种意义上，设计模式增加了软件维护的难度，特别是它增加了对象之间关联的复杂度。我们总说，重用可以提高软件开发的效率。如果你是大牛，你自然希望你的设计可以被反复使用 10000 年，那就是：当世界消灭的时候，你的设计依然存在。然而，现实是一个系统的设计往往在 5 年之就会被抛弃，这是因为：1，软件技术产生了新的变化，使用新的技术进展的设计，无论如何都比你的设计好

6、；2，硬件环境发生了很大变化，你的设计里对开销或者效率的追求已经没有意义了；3，新的大牛出现了，并且取代了你的位置。应用设计模式会导致设计周期的加长 因为更复杂了，但是很多工程还在设计阶段就已经胎死腹中，再好的设计也没有发挥的余地。当我们向设计模式顶礼膜拜的时候，我们还必须清醒地看到软件生产中非技术层面上的东西往往具有决定性作用。理想固然崇高，但现实总是残酷的。如何看清理想与现实的界限，恐怕是需要我们在实践中不断磨砺而体会出来的。在看完设计模式后，不妨反问以下自己，这些模式终究能给你带来什么？InterpreterInterpreter、IteratorIterator、StateState

7、模式模式jz*.Interpreter 模式：这个模式主要试图去解释一种语言。如果你学过形式语言，那么这个模式对你来说是多余的。Iterator 模式：这个模式试图隐藏集合的部表示，又同时可以使用户依次访问集合中的元素。现在 STL 和 Java 的跌代器就是应用这个模式的结果。State 模式：这个模式的意图是允许对象在其状态改变时修改其行为，好似对象改变了。这个模式的应用场景是当对象的行为依赖于对象的状态时。为了实现这个模式，我们可以为每个状态下的行为实现一个类，当对象的状态发生改变，它调用不同状态对象的实例方法。注意，以前可能需要使用switch 或者 if 语句进展分支转换，现在那么利

8、用多态机制完成。FlyweightFlyweight 模式模式这个模式利用共享有效的支持大量的细粒度的对象。比方，编辑软件中，一篇文章有很多个字符，我们可以对每个字符对象生成一个对象，如果这篇文章有几M 个文字，那么对象的数量肯定是不能容忍的。使用Flyweight 模式，我们将所有的文字对象共享起来，文章中的字符仅仅是指向共享池中的某个对象的索引。在这里要搞清楚一件事情，利用 Flyweight 模式不会有效地减少信息的数量 也就是软件的空间开销，因为无论是否共享，表达这么多信息所需要的编码数量是一定的，所以开销不会大幅减小。只是，这个模式会减少系统中对象的数量，因为大量的对象会被共享。在编

9、辑软件中，字符对象被共享，那么一篇文章中的文字，可以按照段落、格式等等进展结组，一组文字构成一个对象，这样对象从单个文字变成一组文字，数量大幅减少。在使用 Flyweight 模式需要注意的一点，由于对象被共享了，因此这些对象没有各自的属性，那么根据上下文环境，我们在使用这些对象的时候，必须向它传递一些参数。在编辑软件中，这些参数可能就是字体、字号、颜色等等信息。使用 Flyweight 模式还有一个好处，那就是我们可以在不修改系统的情况下增加享元。mandmand 模式模式jz*.mand 模式，将一个请求封装为一个对象。这样，你可以向客户端发送不同请求的参数，排队或记录请求，同时可以支持不

10、能执行的请求。在软件中，不同的模块、对象之间经常会各种调用，或者我们称之为请求。传统的方法，我们将请现为函数调用。这样做是最简单的方法，但却在无形之中增加了模块之间的耦合度。当请求发生很大变化的时候，系统将变得很难维护。与此同时，当效劳端 承受请求的一端增加或者删除一个请求的时候，按照传统的方法，客户端发送请求的一端也必须重新编译这一点在删除请求的时候最明显，这样系统才能正确运行。使用 mand 模式的一个核心思想就是，效劳端提供一个统一的请求处理接口，客户端那么通过调用接口向效劳端发送请求，这些请求被封装成对象的形式或者其等价形式。在设计模式中，“四人团并没有强调统一接口的事情，它强调了另一

11、个方面，那就是封装请求。事实上，封装一个请求总是要求有一个地方来承受和处理这个请求的，这个地方实际上就是统一请求接口。在设计模式中，请求被封装成一个mand 对象，这个对象保存着请求类型、参数等信息，效劳端收到这个命令后就会执行mand 对象中的 Execute()函数，这个函数具体实现了真正的操作。这种实现方法可以保证增加新的请求而不必重新编译效劳端。我个人认为，mand 模式的另一个形式就是在效劳端实现各种操作，mand 对象只是负责指明请求的类型，这样，当效劳器端发现请求不正确时，可以忽略该请求。和上一种形式相比，这种形式更加简洁因为可以不真正实现mand 对象，在 C+中可以使用不定参

12、数实现，但是缺少灵活性。mand 模式使得记录请求成为了可能，我们可以捕获系统中的请求对象，记录他们。positeposite 模式模式posite 模式的意图是“将对象组合成树形构造表示整体-局部的层次构造。posite 使得用户对单个对象和组合对象的使用更具有一致性。jz*.在 Word 中我们经常会将一些图元进展“组合，组合以后的图形还可以向简单图元那样进展移动、变形等等操作；除此以外，在Word 中，我们对于一个字符、一个词组、一句话、一个段落，甚至是整篇文章的操作是一样的，我们都可以进展剪切、复制，进展字体与大小的调整，进展颜色的变换。这些例子都是posite 模式的实例，我们将简单

13、的元素组合成复杂的元素，然后还可以像操作简单元素那样操作组合元素。posite 模式将子元素组织成树型，实际上，组织成图型也没有问题。用户总是喜欢组合简单元素，一方面，用户可以通过这样的组合来进展抽象，另一方面，用户可以通过组合化简繁琐的操作。posite 模式在各种可视化编辑软件中应用得最为广泛。另一使用 posite 的经典例子是 Java 的 Swing 系统。所有的 Swing 组件都是继承自一个叫做Jponent 的接口，因此，我们对一个JFrame 的操作和对一个 utton 的操作是一样的。这同时也使得，JFrame 在管理自己的子元素时，它不需要知道他们是一个utton 还是一

14、个 JPanel，对它来说，这只是一个 Jponent。实现 posite 模式的关键是良好设计的接口，人们应该对可能的元素简单的、组合的进展分析，并设计出通用的操作。尽可能的保证接口操作对所有元素都是有意义的，否那么就应该将那些只对局部元素有意义的操作下放到子类中。ProxyProxy 模式模式按照“四人团的说法，Proxy 模式可以为控制另一个对象而提供一个代理或者占位符。这个模式可以使我们在真正需要的时候创立对象，如果我们不需要这个对象，Proxy 模式会为我们提供一个占位符。如果我们有大量这样消耗很大的对象的时候，我们就可以使用Proxy 模式，初始情况下，Proxy 模式只会提供占位

15、符而不会真正创立对象，但是对于使用者来说，他看到是真正的对象而不是一个代理。一旦使用者需要获得或者更改对象属性的时候，Proxy 模式就会创立该对象，在此之后，我们就可以通过代理访问真正的对象了。在 Word 里面应该是使用了 Proxy 模式。翻开一篇含图的很长的文档时，大局部的图片都不会被载入，而仅仅是提供占位符，只有当用户准备观察这一页的时候，代理才会真正载入图片。和 Singleton 模式一样，Proxy 模式都是保证我们可以按需分配对象，不同的是，Singleton模式还会保证在全局围使用同一个对象实例，而Proxy 那么没有这个功能。jz*.VisitorVisitor 模式模式

16、按照“四人团的说法，Visitor 模式的意图为：将元素的操作表示成一种构造。这样 Visitor模式可以使你在不修改元素构造的前提下增加新的操作。考虑一个链表，我们需要一个求得最大元素的操作，这个操作可能是遍历每个节点，然后求的最大值。这个时候我们又需要一个为每个元素加1 的操作，这个操作还需要遍历每个节点，同时将每个元素加1。与之类似，还会有很多其他的针对元素操作，他们的特点都是要遍历链表。这个时候可以使用Visitor 模式，结点类负责依次遍历，并调用Visitor 类中的函数，而 Visitor 类的具体实现那么负责完成功能。这里需要注意的是，Visitor 类只能是一个接口，针对不同

17、的操作需要有不同的具体实现，针对不同的具体元素，需要设计不同的操作。每个元素负责选择自己应该调用的操作，Visitor子类负责实现具体功能。一个的应用是 SmallTalk-80 的编译器，在编译时，编译器需要建立一棵语法树。在这个时候，它使用了Visitor 模式，针对不同的操作，比方：类型检查、代码生成等操作实现不同的Visitor 具体类，Visitor 类中针对不同的节点类型提供不同的操作接口，具体的节点负责选择调用哪种接口，这像是一种回调操作。ObserverObserver 模式模式按照“四人团的说法，Observer 模式的意图是“定义对象间的一种一对多的依赖关系，当一个对象的状

18、态发生改变时，所有依赖于它的对象都得到通知并被自动更新。实际应用的例子是，比方建模工具中，假设干条线形元素附着在一个块状元素上，当块状元素的大小、位置发生变化，那些线形元素也需要进展改变，这个时候我们就可以应用Observer 模式，在块状元素和线形元素之间建立一对多的关系，并利用这一模式进展维护。Observer 模式首先构造一个 Observer 类，在这个类中具有一个update 函数。被依赖的对象拥有它，依赖的对象被注册到Observer 中，当被依赖的对象发生变化的时候，就调用 update函数更新所有依赖它的对象。更新的方式由update 函数具体实现。jz*.还有一个现实中的例子

19、，各个部门之间进展通讯，当一方发出新的信息时，按照传统的方法它必须告诉所有其他部门。如果使用Observer 模式，那么产生新消息的一方只需要告知Observer，由 Observer 通知其他方面。TemplateTemplate MethodMethod 模式模式Template Method 模式的意图是：“定义一个操作中的骨架，而将一些步骤延迟到子类中。这使得子类可以不改变一个算法的构造即可以重定义该算法的某些特定步骤。这一模式和 Strategy 模式似乎和相似，但是他们的关注点不同。策略模式主要用于算法的替换，但是模板方法模式主要用于算法中特定步骤地替换。一个应用模板方法模式的例子

20、是数据库操作。对于数据库操作可以有很多中，比方查询、更新。查询又可以分为连接数据库、发送请求命令、解析结果等等步骤。对于不同的数据库，比方Oracle 和 SQL2000，它们连接数据库、命令格式可能有所不同，但是就查询和更新着两个操作来说它们的步骤是一样的。这个时候，我们可以应用模板方法模式，为查询、更新操作建立一个抽象的算法，具体的步骤交给子类来实现。如果对于策略模式，我们替换的将是查询和更新着两个操作。但是，将 Template Method 模式和 Strategy 模式进展类比是危险的，这两个模式有着很多重要的不同，但这些不同却又是十分的细微，只能意会不能言传。FactoryFact

21、ory MethodMethod 模式模式这一模式的意图是：“定义一个用于创立对象的接口，让子类决定实例化哪一个类。FactoryMethod 是一个类的实例化延迟到其子类。这一模式的关键是掌握“何时应用这一模式，事实上我觉得这也是所有设计模式的关键。一个的应用就是MFC 中关于 Document 和 Frame 之间的关系。通常在生成一个多文档程序时，VC 会为你创立一个 Frame 类和 Document 类，你的 Frame 类可以用来相应 OnFileNew消息，然后创立一个Document 对象。但是对于Windows 的消息系统来说，它并不知道用户程序中创立的 Document 类

22、有什么特性，对于它来说，它所看到是 CFrame 对象和 CDocument对象。Factory Method 模式可以保证其他对象不需要知道具体对象的类型而管理这些对象，这一模式通常用于制定框架。jz*.这一模式和 Abstract Factory 模式很相像，事实上 Abstract Factory 模式可以由一系列 FactoryMethod 模式实现。StrategyStrategy 模式模式Strategy 模式的目的就是“定义一系列的算法，把他们一个个封装起来，并且使他们可以互相替换。如何理解这一模式，首先看下面这个场景：一组数据进展排序，我们可以选择很多中排序算法，这个时候我们定

23、义一个排序策略，然后每个排序算法实现一个具体策略，这样用户就可以在几个不同的排序算法中随意选择和替换了。当然，上面的例子中使用策略模式似乎多此一举，那么假设游戏中的敌人的AI，根据玩家的设定可以有不同的级别。在这种情况下，使用策略模式就是十分必要的了。BridgeBridge 模式模式按照“四人团的说法，Bridge 模式的意图是：将抽象局部与他的实现局部别离，使得他们可以独立的变化。你一定会感到一阵眩晕，不明白这是什么意思。首先应该说明的是“抽象与“实现的含义。在刚刚的那句话中，“抽象与“实现并不是我们在描述类构造时所说的“接口与它的“实现，或者在 Java 中抽象类与他的实现。在这里，“抽

24、象与“实现只得是某种工作，“抽象是说如何完成这项工作，“实现是说“抽象中所用的步骤的实现。一个例子可以很好的说明“抽象与“实现的关系。我们编写一个游戏，这个游戏有两个版本，DX 版本和 OpenGL 版本。我们如何编写这两个版本呢？一种方法是我们在这两个引擎上开发两套独立的游戏，但这显然不是最好的方法。另一个选择是我们将游戏的“抽象局部与“实现局部别离，开发一套“抽象局部，开发两套“实现局部。那么什么是游戏的“抽象局部？很显然就是游戏的绘图 也许用更专业词汇的应该是：渲染 过程，jz*.例如我们如何渲染游戏的人物，这个人物可能是由很多个多边形组合而成的，我们按照一定的方法渲染之后，就可以画出一

25、个人物来。这一局部就可以看作是“抽象。那么另一方面就是“实现局部，在上面的例子中，“实现局部就是如何绘制根底的线条、填充颜色，甚至是初始化屏幕等等。这些“实现和具体的引擎密切相关。为什么说我们可以将“抽象和“实现别离，使得他们可以各自变化呢？假设现在要开发新的游戏，或者这个游戏升级了，在其中出现了新的人物，那么“抽象局部就发生了变化，但是具体“实现没有变化，因此这个游戏还可以继续在你的计算机上运行。另一方面，如果游戏需要进展移植，目标平台的图形系统发生了变化，你可能需要使用新的绘图引擎，这个时候，你只需要利用新的引擎实现根本的“实现操作，原始的程序就可以在新的平台上运行略去重新编译的问题。Fa

26、cadeFacade 模式模式Facade 模式的目的就是给子系统提供一个统一的接口。现在的软件都是按照模块进展划分，对不同的模块分别进展编程。但是在用户开来，不同的模块应该具有统一的接口，换句话说，我们应该可以通过统一的接口访问系统中的所有功能。有一个很典型的例子就是编译系统。通常我们将编译系统分解为：pile 和 Link 两个步骤。一个 pile 又可以分解为词法分析、语法分析、语义分析、中间代码生成等等步骤。对于用户来讲，我们不可能将这些模块分别提供应他们，让他们依次调用。相反的，我们应该提供一个统一的接口，使得用户可以方便的使用各个功能，例如IDE。Facade 模式在强调模块化开发

27、的同时也强调模块的统一，统一的接口也有利于子系统中模块部的变化。对于开发大型系统来说，Facade 模式是不可缺少的。DecoratorDecorator 模式模式按照“四人团的说法，Decorator 模式的意图是：动态的给一个对象添加一些额外的职责。值得注意的是，这个对象不知道他增加的是什么职责。jz*.这个模式的一个典型应用实例是：Java 的流。一个文件流Java.IO.File用于读写文件，如果你想使用文件缓冲，你可在为File添加一个BufferedInputStream或者BufferedOutputStream外观，这样这个文件流就具有了缓冲。再如一个Reader 类，你可以给

28、他增加缓冲BufferedReader，然后你还可以给这个缓冲流增加一些格式化读取的能力。Decorator 模式可以动态的增加对象的额外的职责，这也有利于将额外的功能分别实现，使得用户可以自由组合。AdapterAdapter 模式模式有一天你在网上找到一个库，你打算把它应用到你的程序当中去，但是你发现这个库的函数不符合你的风格，你会怎么办？一个很简单的方法就是使用Adapter 模式。Adapter 模式的目的就是将一个类的接口转换为用户希望的接口，使得由于接口不兼容而不能一起工作的各个类可以一起工作。例如在一个软件里面可能使用了以前一个版本的类库。不幸的是这个类库的效率极高却和现在的接口

29、不兼容，为了继续复用这个类库我们就可以使用Adapter 模式，在原来的类库和现在的接口中间实现一个适配器，使得我们可以用现在的构造调用以前的类库。例如一个绘图程序这种事情总是出现在这类程序中，以前的类库中提供绘制直线的方法 DrawLine，但是新的接口要求绘图系统还要提供绘制矩形、折线形的方法，为了复用这个类库，我们实现一个 Adapter 类，这个类中利用以前的绘图系统提供的方法实现了新的接口功能。SingletonSingleton 模式模式这可能是最简单的一个模式了，但是他的应用却是最多的。这个模式的目的就是保证一个对象只有一个实例，并且提供一个全局的访问点。jz*.那么这个模式的怎

30、么实现呢？很简单，你首先必须为这个类设置一个指针Java 中是引用，然后提供一个方法用来获得这个类的实例。在这个方法中首先判断这个指针是否为空，如果是，那么创立一个实例，否那么直接返回这个指针。虽然我们可以提供一个全局访问点，但实际上这个模式也可以应用到局部。应用这个模式一个好处就是可以“按需分配，同时也封装了对象的获取过程。不管如何，我觉得应该尽可能的应用这个模式，虽然这会让你感到很烦这个模式在实现过程中可以进展变化，例如在Instance()方法上添加参数 Boolean bAlloc，用于指定当实例不存在的时候是否进展创立。这样做是考虑到，有些时候我们获得实例的目的不是为了修改，而是为了

31、读取。这个时候，返回一个空实例和返回一个没有被修改正的实例在逻辑上是一样的。例如，这个对象是一个数组时，一个“空数组和一个“空白的数组是一样的。BuilderBuilder 模式模式按照“四人团的说法，Builder 模式的目的是：将一个复杂对象的构建与他的表示别离，使得同样的构建过程可以创立不同的表示。一个典型的例子是：文件的格式转换。假设一个 RTF 文件，我们可以将它转换成不同的格式，比方 TXT、DOC、PDF 等等。在这些目标格式的文件中，有些文件格式中保存文本字体比方 DOC，有些可能不保存比方TXT。当我们开场转换过程时，按照RTF 文件自己的格式进展分析转换。转换的过程是一样的

32、，但是不同的目标文件格式对于不同的转换请求的处理是不同的，比方 TXT 文件转换将会忽略所有的文本格式控制符，但是DOC 文件将会把 RTF 的控制符转换为自己的控制符。应用 Builder 模式，我们可以实现不同的具体生成器，对于一样的请求产生不同的结果。Director 负责向 Builder 发送不同的生成请求，在刚刚的例子中，RTF 文档的分析器可以看作是 Director，文档转换器可以看作是Builder。另一个可以想到的例子是一个编成开发环境，我们可能对源程序进展语法分析，但是分析的目的可能不同，有的分析可能是用来生成代码，有的可能是用来形成智能感知。不管如何，语法分析的过程是一

33、样的，因此将语法分析看成一个 Director，代码生成和形成智能感知看作是两个ConcreteBuilder，对于一样的分析请求产jz*.生不同的动作。例如当分析器发现一个函数以后，就会向 Builder 发送请求，如果这个 Builder实例是代码生成器，那么它可能会记录这个函数的入口地址，如果这个Builder 实例是智能感知器，那么它可能像数据库中插入这个函数的信息。AbstractAbstract FactoryFactory 模式模式这个模式的关键就是设计一个AbstractFactory 接口，这个接口提供了一系列抽象函数用来创立各种对象。这个模式的意图就是使用一个统一的接口用以

34、创立不同具体对象。假设这样一个场景，在不同配置的计算机上完成显示和打印任务，对于高配置的计算机我们使用高分辨率的驱动，在低配置上的机器使用低分辨率的驱动。这个时候，我们可以将显示驱动看成 ProductA，打印驱动看成ProductB；每种驱动具有两种分辨率，分别对应上下两种配置。这个时候在创立配置系统驱动的时候，我们就可以使用AbstractFactory 模式，为上下两种配置实现两个具体工厂类，分别用于创立对应的驱动。所有的用户不用关心当前是什么配置的计算机，它只需要调用统一的抽象工厂接口就可以获得对应的驱动。使用这个模式还需要注意的是，产品对象也必须具有良好的设计，以至于用户不需要关心具体的产品是哪种类型就可以通过抽象产品的接口使用这个产品。使用这个模式可以令用户无需关心具体环境，降低代码耦合度，使得程序构造更加清晰。缺陷是当每个产品的具体实现有很多种时，实现的具体工厂类的数量会迅速膨胀，而且它不能对环境的改变进展立即响应。jz*