第七周作业

                                                                                                            设计模式学习总结

 

 

       设计模式是个好东西，它给出了很多设计中的技巧与思路，对于很多优秀的设计，它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的，而是他们搜集了其他人优秀的设计，加以整理出来的，他们不是这些模式的创造者，仅仅是整理者。应用设计模式会给我们带来很多好处：软件将变得更加灵活，模块之间的耦合度将会降低，效率会提升，开销会减少。更重要的是，设计模式就好像美声唱法中的花腔，让你的设计更加漂亮。总的来说，设计模式似乎将软件设计提升到艺术的层次。设计模式已经被广泛的应用了，在现在很多的图形界面框架都使用了MVC模式，大量跌代器模式的应用，彻底改变了我们对集合的操作方式。不仅如此，应用了设计模式的设计，往往被看成为优秀的设计。这是因为，这些设计模式都是久经考验的。在学习和使用设计模式的时候，往往出现一个非常严重的误区，那就是设计模式必须严格地遵守，不能修改。但是设计模式不是设计模型，并非一成不变。正相反，设计模式中最核心的要素并非设计的结构，而是设计的思想。只有掌握住设计模式的核心思想，才能正确、灵活的应用设计模式，否则再怎么使用设计模式，也不过是生搬硬套。当然，掌握设计模式的思想，关键是要仔细研究模式的意图和结构。一个模式的意图，就是使用这个设计模式的目的，体现了为什么要使用这个模式，也就是需求问题。这个模式的结构，就是如何去解决这个问题，是一种手段、一种经典的解决方法，这种解决方法只是一种建议。两个方面结合起来，明白为什么需要设计模式，同时明白了如何实现这个模式，就容易抓住模式的本质思想。在抓住意图和结构的基础上，实践也是掌握设计模式的必要方法。当然，设计模式必须在某个场景下得到应用才有意义

创建型模式如下

Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系

Factory Methid，Abstract Factory，Builder都需要一个额外的工厂类负责实例化“”易变对象“”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象

如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder， Prototype）

结构型模式

Interpreter模式：这个模式主要试图去解释一种语言。如果你学过形式语言，那么这个模式对你来说是多余的。

Iterator模式：这个模式试图隐藏集合的内部表示，又同时可以使用户依次访问集合中

元素。现在STL和Java的跌代器就是应用这个模式的结果。

State模式：这个模式的意图是允许对象在其状态改变时修改其行为，好像对象改变了。这个模式的应用场景是当对象的行为依赖于对象的状态时。为了实现这个模式，我们可以为每个状态下的行为实现一个类，当对象的状态发生改变，它调用不同状态对象的实例方法。注意，以前可能需要使用switch或者if语句进行分支转换，现在则利用多态机制完成。

Flyweight模式

这个模式利用共享有效的支持大量的细粒度的对象。比如，编辑软件中，一篇文章有很多个字符，我们可以对每个字符对象生成一个对象，如果这篇文章有几M个文字，那么对象的数量肯定是不能容忍的。使用Flyweight模式，我们将所有的文字对象共享起来，文章中的字符仅仅是指向共享池中的某个对象的索引。在这里要搞清楚一件事情，利用Flyweight模式不会有效地减少信息的数量（也就是软件的空间开销），因为无论是否共享，表达这么多信息所需要的编码数量是一定的，所以开销不会大幅减小。只是，这个模式会减少系统中对象的数量，因为大量的对象会被共享。在编辑软件中，字符对象被共享，那么一篇文章中的文字，可以按照段落、格式等等进行结组，一组文字构成一个对象，这样对象从单个文字变成一组文字，数量大幅减少。在使用Flyweight模式需要注意的一点，由于对象被共享了，因此这些对象没有各自的属性，那么根据上下文环境，我们在使用这些对象的时候，必须向它传递一些参数。在编辑软件中，这些参数可能就是字体、字号、颜色等等信息。使用Flyweight模式还有一个好处，那就是我们可以在不修改系统的情况下增加享元。

Command模式

Command模式，将一个请求封装为一个对象。这样，你可以向客户端发送不同请求的参数，排队或记录请求，同时可以支持不能执行的请求。在软件中，不同的模块、对象之间经常会各种调用，或者我们称之为请求。传统的方法，我们将请求实现为函数调用。这样做是最简单的方法，但却在无形之中增加了模块之间的耦合度。当请求发生很大变化的时候，系统将变得很难维护。与此同时，当服务端（接受请求的一端）增加或者删除一个请求的时候，按照传统的方法，客户端（发送请求的一端）也必须重新编译（这一点在删除请求的时候最明显），这样系统才能正确运行。使用Command模式的一个核心思想就是，服务端提供一个统一的请求处理接口，客户端则通过调用接口向服务端发送请求，这些请求被封装成对象的形式（或者其等价形式）。在《设计模式》中，“四人团”并没有强调统一接口的事情，它强调了另一个方面，那就是封装请求。事实上，封装一个请求总是要求有一个地方来接受和处理这个请求的，这个地方实际上就是统一请求接口。在《设计模式》中，请求被封装成一个Command对象，这个对象保存着请求类型、参数等信息，服务端收到这个命令后就会执行Command对象中的Execute()函数，这个函数具体实现了真正的操作。这种实现方法可以保证增加新的请求而不必重新编译服务端。我个人认为，Command模式的另一个形式就是在服务端实现各种操作，Command对象只是负责指明请求的类型，这样，当服务器端发现请求不正确时，可以忽略该请求。和上一种形式相比，这种形式更加简洁（因为可以不真正实现Command对象，在C++中可以使用不定参数实现），但是缺少灵活性。 Command模式使得记录请求成为了可能，我们可以捕获系统中的请求对象，记录他们。

Facade模式

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

Decorator模式

按照“四人团”的说法，Decorator模式的意图是：动态的给一个对象添加一些额外的职责。值得注意的是，这个对象不知道他增加的是什么职责。这个模式的一个典型应用实例是：Java的流。一（Java.IO.File）用于读写文件，如果你想使用文件缓冲，你可在为File添加一个BufferedInputStream或者BufferedOutputStream外观，这样这个文件流就具有了缓冲。再如一个Reader类，你可以给他增加缓冲BufferedReader，然后你还可以给这个缓冲流增加一些格式化读取的能力。Decorator模式可以动态的增加对象的额外的职责，这也有利于将额外的功能分别实现，使得用户可以自由组合。

Adapter模式

有一天你在网上找到一个库，你打算把它应用到你的程序当中去，但是你发现这个库的函数不符合你的风格，你会怎么办？一个很简单的方法就是使用Adapter模式。Adapter模式的目的就是将一个类的接口转换为用户希望的接口，使得由于接口不兼容而不能一起工作的各个类可以一起工作。例如在一个软件里面可能使用了以前一个版本的类库。不幸的是这个类库的效率极高却和现在的接口不兼容，为了继续复用这个类库我们就可以使用Adapter模式，在原来的类库和现在的接口中间实现一个适配器，使得我们可以用现在的结构调用以前的类库。例如一个绘图程序（这种事情总是出现在这类程序中），以前的类库中提供绘制直线的方法DrawLine，但是新的接口要求绘图系统还要提供绘制矩形、折线形的方法，为了复用这个类库，我们实现一个Adapter类，这个类中利用以前的绘图系统提供的方法实现了新的接口功能。

Singleton模式 

这可能是最简单的一个模式了，但是他的应用却是最多的。这个模式的目的就是保证一个对象只有一个实例，并且提供一个全局的访问点。那么这个模式的怎么实现呢？很简单，你首先必须为这个类设置一个指针（Java中是引用），然后提供一个方法用来获得这个类的实例。在这个方法中首先判断这个指针是否为空，如果是，则创建一个实例，否则直接返回这个指针。虽然我们可以提供一个全局访问点，但实际上这个模式也可以应用到局部。应用这个模式一个好处就是可以“按需分配”，同时也封装了对象的获取过程。不论如何，我觉得应该尽可能的应用这个模式，虽然这会让你感到很烦……这个模式在实现过程中可以进行变化，例如在Instance()方法上添加参数Boolean bAlloc，用于指定当实例不存在的时候是否进行创建。这样做是考虑到，有些时候我们获得实例的目的不是为了修改，而是为了读取。这个时候，返回一个空实例和返回一个没有被修改过的实例在逻辑上是相同的。例如，这个对象是一个数组时，一个“空数组”和一个“空白的数组”是相同的。

Builder模式

按照“四人团”的说法，Builder模式的目的是：将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示。一个典型的例子是：文件的格式转换。假设一个RTF文件，我们可以将它转换成不同的格式，比如TXT、DOC、PDF等等。在这些目标格式的文件中，有些文件格式中保留文本字体（比如DOC），有些可能不保留（比如TXT）。当我们开始转换过程时，按照RTF文件自己的格式进行分析转换。转换的过程是一样的，但是不同的目标文件格式对于不同的转换请求的处理是不同的，比如TXT文件转换将会忽略所有的文本格式控制符，但是DOC文件将会把RTF的控制符转换为自己的控制符。应用Builder模式，我们可以实现不同的具体生成器，对于相同的请求产生不同的结果。Director负责向Builder发送不同的生成请求，在刚才的例子中，RTF文档的分析器可以看作是Director，文档转换器可以看作是Builder。另一个可以想到的例子是一个编成开发环境，我们可能对源程序进行语法分析，但是分析的目的可能不同，有的分析可能是用来生成代码，有的可能是用来形成智能感知。不论如何，语法分析的过程是相同的，因此将语法分析看成一个Director，代码生成和形成智能感知看作是两个ConcreteBuilder，对于相同的分析请求产生不同的动作。例如当分析器发现一个函数以后，就会向Builder发送请求，如果这个Builder实例是代码生成器，那么它可能会记录这个函数的入口地址，如果这个Builder实例是智能感知器，那么它可能像数据库中插入这个函数的信息。

Abstract Factory模式

这个模式的关键就是设计一个AbstractFactory接口，这个接口提供了一系列抽象函数用来创建各种对象。这个模式的意图就是使用一个统一的接口用以创建不同具体对象。假设这样一个场景，在不同配置的计算机上完成显示和打印任务，对于高配置的计算机我们使用高分辨率的驱动，在低配置上的机器使用低分辨率的驱动。这个时候，我们可以将显示驱动看成ProductA，打印驱动看成ProductB；每种驱动具有两种分辨率，分别对应高低两种配置。这个时候在创建（配置）系统驱动的时候，我们就可以使用AbstractFactory模式，为高低两种配置实现两个具体工厂类，分别用于创建对应的驱动。所有的用户不用关心当前是什么配置的计算机，它只需要调用统一的抽象工厂接口就可以获得对应的驱动。

使用这个模式还需要注意的是，产品对象也必须具有良好的设计，以至于用户不需要关心具体的产品是哪种类型就可以通过抽象产品的接口使用这个产品。使用这个模式可以令用户无需关心具体环境，降低代码耦合度，使得程序结构更加清晰。缺陷是当每个产品的具体实现有很多种时，实现的具体工厂类的数量会迅速膨胀，而且它不能对环境的改变进行立即响应。

 

                                               设计模式归类如上