设计模式1设计模式概述.docx
《设计模式1设计模式概述.docx》由会员分享，可在线阅读，更多相关《设计模式1设计模式概述.docx（20页珍藏版）》请在冰点文库上搜索。
设计模式1设计模式概述
第1章设计模式概述
1.1概述
设计模式是面向对象技术的“刀刃”部分。
面向对象分析工具、数据、以及讲座都结合了设计模式。
关于设计模式的学习组到处都有。
人们常常听到这样的建议：
只有在掌握了基本面向对象技术之后，才能学习设计模式。
但我发现事实正好相反：
在学习面向对象技术的早期学习设计模式，可以大大帮助您提高对面向对象分析、设计的理解。
1.1.1模式的起源
很多年前，一个名叫ChristopherAlexander的建筑师自问：
“质量可以客观评价吗？
”。
美的东西对于看者都是美的吗？
人们是否会同意一些东西是美的而另一些不是？
现在，让Alexander感兴趣的一种美就是建筑质量：
是什么让我们感觉一个建筑设计是优秀的？
比如说，如果有人要为一栋房子设计入口，他/她怎么能知道自己的设计是否优秀呢？
我们知道那些设计优秀吗？
这样的评价有客观根据吗？
对我们共同观点的描述有客观根据吗？
Alexander认为建筑学中的确存在这样的客观根据。
“评价一个建筑是否美观”并不仅仅只是一个品位的问题。
我们可以通过可以衡量的客观标准来描述美观程度。
文化人类学也显示出同一件事。
这门学科指出：
各种文化在很大范围内都共同认为“一个优秀的设计一定是美的”。
不同文化评价优秀设计的标准已经超越了各自的信仰。
我相信，有一些作为评价设计的客观基础的超越性的模式存在。
文化人类学的一个分支，就是寻找这些模式来描述一种文化的行为和价值。
设计模式背后的主张，是同样可以客观衡量软件系统的质量。
如果您接受“优质设计可以识别、描述”的观点，那么您将如何创建一个优质的设计呢？
我可以想象Alexander这样问他自己：
优质设计能表现而劣质设计不能表现的东西是什么？
以及劣质设计能表现而优质设计不能表现的东西又是什么？
为了研究这个问题，Alexander观察了许多建筑物、城镇、街道、以及几乎所有其他模样的人类为自己创造的生活空间。
他发现，对于任何特定的建筑物，优秀的结构之间总有一些相同之处。
建筑结构彼此之间互不相同，但它们类型相同。
尽管他们相互不同，他们仍然可以都是高质量的。
比如说，两个门廊的结构可能看起来不同，但却都可能是非常高质量的。
他们可能为不同的房屋解决不同的问题。
一个门廊可能是引道和前门之间的过渡。
另一门廊则可能是炎热天气中的阴凉处。
或者两个门廊可能用不同的方法解决同一个问题（过渡）。
Alexander懂得了这一点。
他明白结构可以与他们要解决的问题相分离。
因此，在他“鉴别和描述设计质量的一致性”的探索过程中，Alexander认识到，他必须观察被设计以解决同样问题的不同结构。
举个例子，展示了“区分入（demarkinganentryway）”的问题的两个解决方案。
如图1-1所示。
图1-1解决相同问题的不同结构
Alexander发现，通过这样的方式来观察解决相似问题的不同解决方案，缩小他的关注焦点，他可以东西优质设计之间的相似之处。
他把这些相似之处称为模式。
他把模式定义为“在一个情景下的问题解决方案”。
每个模式，通过一种让您可以无数次使用这一解决方案、而不必再次重复同样工作的方式，描述一个在我们你的环境中重复出现的问题、并描述该问题解决方案的核心。
每个模式的描述需要由四个部分组成，分别是：
模式的名称。
一个助记名，它用一两个词来描述模式的问题、解决方案和效果。
命名一个新的模式增加了我们的设计词汇。
设计模式允许我们在较高的抽象层次上进行设计。
基于一个模型词汇表，我们自己以及同时之间就可以讨论模式并在编写文档的时候使用它们。
模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。
找到恰当的模式名也是我们设计模式编目工作的难点之一。
模式的目的，它要解决的问题。
描述了应该在何时使用模式。
它揭示了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。
也可能描述了导致不灵活设计的类或对象结构。
有时候，问题部分会包括使用模式必须满足的一系列先决条件。
如何实现它。
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。
因为模式就像一个模板，可应用于多种不同的场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样做一个具有一般意义的元素组合（类或对象组合）来解决问题。
为了实现它所必须考虑的限制和约束。
描述了模式应用的效果及使用模式应权衡的问题。
尽管我们描述设计决策时，并不总提到模式效果，但他们对于评价设计选择和理解使用模式的代价及好处具有重要意义。
软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。
因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
Alexander认为模式可以解决可能遇到的几乎所有建筑学问题。
他还更进一步的认为模式可以结合在一起使用，以解决更复杂的建筑学问题。
1.1.2软件设计模式
这些建筑学材料对我们软件开发者有什么作用呢？
在二十世纪九十年代前期，一些聪明的开发者偶然发现了Alexander关于模式的研究成果。
他们想知道对于建筑学模式适用的东西是否对于软件开发也适用。
软件中是否有不断重复出现、可以用某种相同方式解决的问题？
是否可能用“按照模式、首先识别出模式然后在模式的基础上创建特定的解决方案”的方法来设计软件？
这些人感觉到，这两个问题的答案都毫不含糊的是“yes”。
下一步的工作就是，识别出几个模式，并制定出收录模式的标准。
尽管在九十年代前期有很多人从事于设计模式的工作，对这个缺乏经验的躯体影响最深刻的书却是Gamma、Helm、Johnson和Vlissides的《设计模式：
可复用面向对象软件的基础》。
出于对他们重要成果的公认，这四个作者通常被亲切的称为“GOF（GangofFour——四人帮）”。
该书重要意义如下：
软件中是否有不断重复出现、可以用某种相同方式解决的问题？
它将设计模式的思想应用于软件设计。
它描述了收录和描述设计模式的一个结构。
他收录了23个模式。
它在这些模式的基础上提出了面向对象策略及方法的原则。
需要认识到：
这几位作者并不是书中这些模式的创建者。
实际上，这几位作者识别出了那些已经存在于软件社群中的模式、那些反应出“从特定问题的优质设计中学到的经验”的模式（请注意与Alexander著作中的相似性）。
今天，已经有了集中不同描述设计模式的格式。
因为这并不是一本关于编写设计模式的书，所以我们不用去评价什么是描述模式的最佳结构；但是，任何一个描述都需要包括表1-1所罗列的项目。
表1-1模式的基本要素
项目
描述
名称
每个模式都有一个独一无二的名称，人们用名称来鉴别模式。
意图
模式的目的。
问题
模式试图解决的问题。
解决方案
对于自己出现的场景中的问题，模式怎样提供一个解决方案。
参与者和协作
模式包括的实体。
效果
使用模式的效果。
使用模式的同时，研究其约束。
实现
怎样实现模式。
指实现模式的具体表现形式，不能想模式本身那样被分析。
效果被用于设计模式，并且常常被无戒。
在日常的用法中，“效果（consequence）”这个次并不带褒义。
（您永远不会听到有人说“我中了彩票！
效果是我不必再去工作了！
”）但是，在设计模式群体中，“效果”只能是“原因和结果”。
也既是说：
如果您用某种方法实现这个模式，它将怎样发生影响、怎样被现有的约束影响。
1.1.3设计模式的作用
现在您已经对“什么是设计模式”有了一个了解，您可能还会问：
“为什么要学习它呢？
”学习模式的理由有如下几点：
复用解决方案：
通过复用已经建立的设计，我们为自己的问题找到了更高的起点并避免了绕弯路。
我们应受益于学习别人的经验，不必再为普通、重复的问题重新设计解决方案。
建立通用的属于：
交流与协作都需要一个共同的词汇基础、一个对问题的共同观点。
设计模式在项目的分析和设计阶段提供了一个通用的参考点。
在问题上、在设计和面向对象的过程中，模式给您一个更高层次的视角。
这样的视角将您从“过早处理细节”的暴政中解放出来。
这是我们学习设计模式最重要的原因，它将改变您的思想，让你成为一个更有力的分析者。
为了说明这一优点，我们将在这里引用两个木匠之间的一段关于“如何为橱柜制作抽屉”的谈话。
假设两个木匠正在讨论如何为橱柜制作抽屉的问题，对话如下：
木匠1：
您认为我们应该怎样制作这些抽屉呢？
木匠2：
唔，我想我们应该这样做结合的部分：
在木材上直锯下去，然后回转45度锯，然后再直锯下去，在朝另一个方向回转45度锯，再直锯下入，然后……
现在，您的工作就是弄明白他们究竟在说些什么！
难道这不是一个很混乱的叙述吗？
木匠2的建议究竟是什么？
细节当然会是这样！
让我们试着把他的叙述画下来，如表1-2所示。
表1-2模式的基本要素
描述
图形
唔，我想我们应该这样做结合部分：
在木材上直锯下去，然后回转45度锯……
……然后再直锯下去，再朝另一个方向回转45度锯，再直锯下去，然后……
……直到您得到一个燕尾接合！
难道这听起来不像您曾经听过的代码复审吗？
可能程序员会这样描述他的代码：
“然后，我们将在这里使用一个whileloop循环来……继续以一串if语句……在这里我使用一个switch来处理……”，您获得了关于代码细节的描述。
，但对于“程序在做什么”，以及“为什么要这么做”的问题，您义务所知！
当然，没有一个自重的木匠会象这样说话。
真正可能发生的是这样：
木匠1：
您认为我们应该怎样制作这些抽屉的转角呢，是“燕尾结合”还是“斜面结合”？
木匠2：
我认识应该使用燕尾结合。
从这里我们已经看到一个本质上的区别。
木匠们讨论的是问题的解决方案在质量上的差异。
他们的讨论是站在一个更高、更抽象的层次上的。
他们可以避免陷入特定解决方案的泥沼。
当木匠说到“斜面结合”时，他的思想中有这个解决方案的以下特征：
它是一个简单的解决方案：
斜面结合是一个容易制造的接合。
您只需要接合木材分别锯出45度的斜面，然后用钉子或胶水将他们接合起来。
如图1-2所示。
它是一个轻量级的解决方案：
斜面接合比燕尾接合弱。
在强压力下，它将不能再接合在一起。
图1-2一个斜面结合
它不太显眼：
斜面结合只有一处锯口，这比燕尾集合的多处锯口更不容易引起注意。
当木匠说到“燕尾接合”时，他的思想中有另一些特征。
这些特征对于一个外行可能并不明显，但任何一个木匠都会清楚的理解它们。
它是一个比较复杂的解决方案：
制作一个燕尾接合涉及更多的问题。
也就是说，实现它的代价更高。
它不受温度和湿度影响：
当这些条件变化时，木材会膨胀或收缩。
但是燕尾接合仍能保持坚固。
它与连接系统无关：
实际上，燕尾接合的工作甚至不需要胶水。
它是一个比较美观的接合：
当制作完成时，它看上去很漂亮。
换句话说，燕尾接合是一个坚固、可靠、美观的接合，但制作比较复杂（所以比较昂贵）。
所以，当木匠1问“我们应该用一个燕尾接合还是一个斜面接合”时，他真正要问的问题是：
“我们应该用一个制作昂贵但既美观又耐用的接合，还是应该只用一个制作快速、不美观的接合”。
您可能会说，这些木匠的讨论实际上存在于两个层次：
他们语言的表面层次，以及他们真正的交谈存在的、对外行人隐藏的、含义更有价值的更高层次（背后层次）。
这样的更高层次就是“木匠模式”的层次，它反映出木匠的真实设计问题。
在第一个例子中，木匠2讨论接合的实现细节，结果模糊了真正的问题。
在第二个例子中，木匠1希望根据接合的代价和质量来决定使用那个接合方案。
谁更有效率？
您愿意跟谁一起工作？
当我说“模式可以帮助您提高思考的层次”时，也就是这个意思。
您将在本书的后面部分学到。
当您像这样提高自己的思考层次之后，您将可以使用新的设计方法。
这才是模式真正的威力所在。
1.1.4模式的优点
设计模式既可以帮助单个开发者的学习，也可以帮助团队开发。
这是因为，团队中的初级成员看到懂得设计模式的高级开发者从模式中获益，于是这些初级成员也想得到这些好处。
这为他们学习这些有力的概念提供了动机。
大多数设计模式还让软件更具可修改性。
因为他们都是经受时间考验的解决方案，所以它们发展成为的结构，可以比首先在脑海中浮现的解决方案更容易处理变化。
设计模式被正确传授时，可以大大增加学习者对基本面向对象设计原则的理解。
在这些课程中，我们首先对面向对象范式做一个简短的介绍。
GOF针对“创建优秀面向对象设计”建议了一些策略。
特别的，他们建议了以下几点：
针对接口编程。
优先使用对象组合，而不是类继承。
找到并封装变化点。
设计模式中的绝大多数都是用了这些策略。
即使您没有学过很多设计模式，学习几个模式也可以让您理解为什么这些策略有用。
这样的理解会成为一种能力，即使您并不直接使用设计模式，您也会在自己的设计问题中使用这些策略。
另一个优点是设计模式让您或您的团队可以为不需要巨大继承体系的复杂问题创建设计方案。
同样，即使您并不直接使用设计模式，“避免庞大的继承体系”也会导致改良的设计。
学习设计模式具有以下优点：
复用现有的、搞质量的、针对常见的重复出现问题的解决方案。
建立通用的术语以改善团队内部的沟通。
将思考转移到更高的视角。
判断是否拥有正确的设计，并不仅仅是一个可以工作的设计。
改善个人学习和团队学习。
改善代码的可修改性。
促进对改良设计的选用，甚至在没有明确使用模式的时候。
发现“庞大的继承体系”的替代方案。
1.2计模式分类
设计模式可以分为三大类，分别是创建型设计模式、行为型设计模式以及结构型设计模式。
1.2.1创造型模式
创建模式（CreationalPattern）是对类的实例化过程的抽象化。
一些系统在创建对象时，需要动态地决定怎样创建对象，创建哪些对象，以及如何组合和表示这些对象。
创建模式描述了怎样构造和封装这些动态的决定。
创建模式分为类的创建模式和对象的创建模式两种。
类的创建模式：
类的创建模式使用继承关系，把类的创建延迟到子类，从而封装了客户端将得到哪些具体类的信息，并且隐藏了这些类的实例是如何创建和放在一起的。
对象的创建模式：
对象的创建模式则把对象的创建过程动态的委派给另一个对象，从而动态地决定客户端将得到哪些具体类的实例，以及这些类的实例是如何被创建和组合在一起的。
创建模式包括以下几种：
1、Singleton——单例模式
单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。
单例模式只应在有真正的“单一实例”的需求时才可使用。
2、Factory——工厂模式
客户类和工厂类分开。
消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时，工厂类也要做相应的修改。
34、FactoryMethod——工厂方法模式
核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化的细节。
4、Builder——建造模式
将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
5、Prototype——原始模型模式
通过给出一个原型对象来指明所要创建的对象类型，然后用复制这个原型对象的方法创建出更多同类型的对象。
原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。
缺点是每一个类都必须配备一个克隆方法。
1.2.2结构型模式
结构模式（StructuralPattern）描述如何将类或者对象结合在一起形成更大的结构。
结构模式描述两种不同的东西：
类与类实例。
根据这一不同，结构模式可以分为类的结构模式和对象的结构模式两种。
类的结构模式：
类的结构模式使用集成来把类、接口等组合在一起，以形成更大的结构。
当一个类从父类继承并实现某接口时，这个新的类就把父类的结构和接口的结构结合起来。
类的结构模式是静态的。
一个类的结构模式的典型例子，就是类形式的适配器模式。
对象的结构模式：
对象的结构模式描述怎样把各种不同类型的对象组合在一起，以实现新的功能的方法。
对象的结构模式是动态的。
结构模式包括以下几种：
1、Facade——门面模式
外部与一个子系统的通信必须通过一个统一的门面对象进行。
门面模式提供一个高层次的接口，使得子系统更易于使用。
每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。
但整个系统可以有多个门面类。
2、Composite——组合模式
组合模式将对象组织到树结构中，可以用来描述整体与部分的关系。
组合模式就是一个处理对象的树结构的模式。
组合模式把部分与整体的关系用树结构表示出来。
组合模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
3、Proxy——代理模式
代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。
代理就是一个人或一个机构代表另一个人或者一个机构采取行动。
某些情况下，客户不想或者不能直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。
客户端分辨不出代理主题对象与真实主题对象。
代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须由系统的其它角色代为创建并传入。
4、Adapter——适配器模式
把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口因不匹配而无法一起工作的两个类能够一起工作。
适配类可以根据参数返还一个合适的实例给客户端。
5、Decorator——装饰模式
装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。
动态给一个对象增加功能，这些功能可以再动态的撤销。
增加由一些基本功能的排列组合而产生的非常大量的功能。
6、Bridge——桥梁模式
将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将它们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
7、Flyweight——享元模式
Flyweight在拳击比赛中之最轻量级。
享元模式以共享的方式高校的支持大量的细粒度对象。
享元模式能做到共享的关键是区分内蕴状态和外蕴状态。
内蕴状态存储在享元内部，不会随环境的改变而有所不同。
外蕴状态是随环境的改变而改变的。
外蕴状态不能影响内蕴装题啊，它们是相互独立的。
将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。
客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。
共享模式大幅度的降低内存中对象的数量。
1.2.3行为模式
行为模式（BehavioralPattern）是对在不同的对象之间划分责任和算法的抽象化。
行为模式不仅仅是关于类和对象的，而且是关于它们之间的互相作用的。
行为模式分为类的行为模式和对象的行为模式两种。
类的行为模式：
类的行为使用集成关系在几个类之间分配行为。
对象的行为模式：
对象的行为模式则使用对象的聚合来分配行为。
行为模式包括以下几种：
1、Command——命令模式
命令模式把一个请求或者操作封装到一个对象中。
命令模式把发出命令的责任和执行命令的责任分隔开，委派给不同的对象。
命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。
系统支持命令的撤消。
2、Observer——观察者模式
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
3、TemplateMethod——模板方法模式
模板方法模式是一种非常简单而又经常使用的设计模式。
先创建一个抽象类，然后声明一些抽象方法来迫使子类实现剩余的逻辑。
不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。
先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。
4、Strategy——策略模式
策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。
策略模式使得算法可以在不影响到客户端的情况下发生变化。
策略模式把行为和环境分开。
环境类负责维持和查询行为类，各种算法在具体的策略类中提供。
由于算法和环境独立开来，算法的增减、修改都不会影响到环境和客户端。
5、ChainOfResponsibleity——责任链模式
在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。
请求在这个链上传递，直到链上的某一个对象决定处理此请求。
客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。
处理这有两个选择：
承担责任或者把责任推给下家。
一个请求可以最终不被任何接收端对象所接受。
6、Interpreter——解释器模式
给定一个语言后，解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。
客户端可以使用这个解释起来解释这个语言中的句子。
解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。
在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。
在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。
每一个命令对象都有一个解释方法，代表对命令对象的解释。
命令对象的等级结构中的对象任何排列组合都是一个语言。
7、Iterator——迭代模式
迭代子模式可以顺序访问一个聚集中的元素，而不必暴露聚集的内部表象。
多个对象聚在一起形成的总体成为聚集，聚集对象是能够包容一组对象的容器对象。
迭代子模式将迭代逻辑封装到一个独立的对子对象中，从而与聚集本分隔开。
迭代子模式简化了聚集的界面。
每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子对象的迭代状态可以是彼此独立的。
迭代算法可以独立于聚集角色变化。
8、Mediator——调停者模式
调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。
从而使他们可以松散耦合。
当这些对象之间的作用发生变化时，不会影响其它的一些对象之间的作用。
保证这些作用可以彼此独立的变化。
调停者模式将多对多的相互作用转化为一对多的相互作用。
调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其它对象的相互作用分开处理。
9、Memento——备忘录模式
备忘录对象是一个用来存储另一个对象内部状态的快照的对象。
备忘录模式的作用是在不破坏封装的条件下，将一个对象的状态捉住、并外部化存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。
10、State——状态模式
状态模式允许一个对象在其内部状态改变的时候改变行为。
这个对象看上去象是改变了它的类一样。
状态模式把所研究的对象的行为包装在不同的状态对象中，每一个状态对象都属于一个抽象状态类的一个子类。
状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。
状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。
当系统的
升级会员 