基于设计模式的学习之旅.docx
《基于设计模式的学习之旅.docx》由会员分享，可在线阅读，更多相关《基于设计模式的学习之旅.docx（71页珍藏版）》请在冰豆网上搜索。
基于设计模式的学习之旅
基于设计模式的学习之旅
-----序言
工作了几年，发现设计模式在开发中的重要，重新温习设计模式。
该系列文章用于记录自己的学习过程，以及和大家分享个人对设计模式的一些理解。
1、什么是设计模式
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
2、设计模式的目的
A、提高系统的延展性
B、提高代码的质量和可阅读性
C、提高个人的能力
3、设计模式介绍
设计模式分类：
创建型、结构型、行为型
3.1 创建型
创建型模式抽象了实例化过程。
它们帮助一个系统独立于如何创建、组合和表示它的那些对象。
一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。
创建型模式包含一下几种：
ABSTRACT FACTORY（抽象工厂）、BUILDER（生成器）、FACTORY METHOD（工厂方法）、PROTOTYPE（原型）、SINGLETON（单件）
模式的意图：
A、抽象工厂：
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
B、生成器：
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
C、工厂方法：
定义一个用于创建对象的接口，让子类决定实例化哪一个类。
Factory Method使一个类的实例化延迟到其子类。
D、原型：
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
E、单件：
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
3.2 结构型
结构型模式涉及到如何组合类和对象以获得更大的结构。
结构型类模式采用继承机制来组合接口或实现。
一个简单的例子是采用多重继承方法将两个以上的类组合成一个类，结果这个类包含了所有父类的性质。
这一模式尤其有助于多个独立开发的类库协同工作。
结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。
因为可以在运行时刻改变对象组合关系，所以对象组合方式具有更大的灵活性，而这种机制用静态类组合是不可能实现的。
结构型模式包含一下几种：
ADAPTER（适配器）、BRIDGE（桥接）、COMPOSITE（组合）、DECORATOR（装饰）、FACADE（外观）、FLYWEIGHT（享元）、PROXY（代理）
模式的意图：
A、适配器：
将一个类的接口转换成客户希望的另外一个接口。
A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
B、桥接：
将抽象部分与它的实现部分分离，使它们都可以独立地变化。
C、组合：
将对象组合成树形结构以表示“部分-整体”的层次结构。
C o m p o s i t e使得用户对单个对象和组合对象的使用具有一致性。
D、装饰：
动态地给一个对象添加一些额外的职责。
就增加功能来说， D e c o r a t o r模式相比生成子类更为灵活。
E、外观：
为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
F、享元：
运用共享技术有效地支持大量细粒度的对象。
G、代理：
为其他对象提供一种代理以控制对这个对象的访问。
3.3 行为型
行为模式涉及到算法和对象间职责的分配。
行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。
这些模式刻划了在运行时难以跟踪的复杂的控制流。
它们将你的注意力从控制流转移到对象间的联系方式上来。
行为类模式使用继承机制在类间分派行为。
行为对象模式使用对象复合而不是继承。
结构型模式包含一下几种：
CHAIN OF RESPONSIBILITY（职责链）、COMMAND（命令）、INTERPRETER（解释器）、ITERATOR（迭代器）、MEDIATOR（中介者）、MEMENTO（备忘录）、OBSERVER（观察者）、STATE（状态）、STRATEGY（策略）、TEMPLATE METHOD（模板方法）、VISITOR（访问者）
模式的意图:
A、责任链：
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
B、命令：
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
C、解释器：
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
D、迭代器：
提供一种方法顺序访问一个聚合对象中各个元素 , 而又不需暴露该对象的内部表示。
E、中介者：
用一个中介对象来封装一系列的对象交互。
中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
F、备忘录：
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
这样以后就可将该对象恢复到原先保存的状态。
G、观察者：
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
H、状态：
允许一个对象在其内部状态改变时改变它的行为。
对象看起来似乎修改了它的类。
I、策略：
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
本模式使得算法可独立于使用它的客户而变化。
J、模版方法：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。
Te m p l a t e M e t h o d使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
K、访问者：
表示一个作用于某对象结构中的各元素的操作。
它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
4、如何选择设计模式
A、考虑设计模式是怎样解决设计问题的
B、浏览模式的意图部分
C、研究模式怎样互相关联
D、研究目的相似的模式
E、检查重新设计的原因
F、考虑你的设计中哪些是可变的
5、如何使用设计模式
A、大致浏览一遍模式
特别注意其适用性部分和效果部分，确定它适合你的问题。
B、回头研究结构部分、参与者部分和协作部分
确保你理解这个模式的类和对象以及它们是怎样关联的。
C、看代码示例部分，看看这个模式代码形式的具体例子
研究代码将有助于你实现模式。
D、选择模式参与者的名字，使它们在应用上下文中有意义
设计模式参与者的名字通常过于抽象而不会直接出现在应用中。
E、定义类
声明它们的接口，建立它们的继承关系，定义代表数据和对象引用的实例变量。
识别模式会影响到的你的应用中存在的类，做出相应的修改。
F、定义模式中专用于应用的操作名称
使用与每一个操作相关联的责任和协作作为指导。
还有，你的名字约定要一致。
G、实现执行模式中责任和协作的操作
实现部分提供线索指导你进行实现。
代码示例部分的例子也能提供帮助。
6、参考信息资料
Gof设计模式、HeadFirst 设计模式、网络上已有的分享资料
-----适配器模式
1、初始适配器模式
2、什么是适配器模式
将一个类的接口转换成客户希望的另外一个接口。
A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
别名：
包装器 Wr a p p e r。
Adapter模式最关键的要求是：
Adapter是对两个功能相近的接口间的适配
3、模式结构图
类适配器使用多重继承对一个接口与另一个接口进行匹配，如下图所示：
对象匹配器依赖于对象组合，如下图所示：
4、模式代码事例
4、1涉及到的类，以及类图
Target：
ISpecialSwitchable
Client：
PatternRun
Adaptee：
IStandardSwitchable
Adapter：
SwitcherAdapter
4、2具体的代码实现
ISpecialSwitchable
IStandardSwitchable
Light
SwitcherAdapter
PatternRun
4、3事例输出结果
5、模式参与者
Target：
ISpecialSwitchable
Client：
PatternRun
Adaptee：
IStandardSwitchable
Adapter：
SwitcherAdapter
6、模式优缺点
A、用一个具体的A d a p t e r类对A d a p t e e和Ta rg e t进行匹配。
B、使得A d a p t e r可以重定义A d a p t e e的部分行为，因为A d a p t e r是A d a p t e e的一个子类。
C、仅仅引入了一个对象，并不需要额外的指针以间接得到 a d a p t e e。
7、模式适用性
A、你想使用一个已经存在的类，而它的接口不符合你的需求。
B、 你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。
C、（仅适用于对象A d a p t e r）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。
对象适配器可以适配它的父类接口。
-----外观模式
1、 初始外观模式
股票：
每个股民直接购买各种类型的股票（普通）
基金：
股民通过跟专家打交道，让专家同意选择要购买的股票（外观）
2、什么是外观模式
为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接载口使得这一子系统更加容易使用。
3、模式结构图
4、模式代码事例
4.1涉及到的类
Façade（FoundFacade）
SubSystem（SotckA、SotckB、SotckC）
4.2具体的代码实现
FoundFacade
SotckA
SotckB
PatternRun
NoPatternRun
4.3事例输出的结果
5、模式优缺点
A、它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
B、它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。
C、如果应用需要，它并不限制它们使用子系统类。
因此你可以在系统易用性和通用性之间加以选择。
6、模式适用性
A、当你要为一个复杂子系统提供一个简单接口时。
B、客户程序与抽象类的实现部分之间存在着很大的依赖性。
C、当你需要构建一个层次结构的子系统时，使用 f a c a d e模式定义子系统中每层的入口点
-----享元模式
1、 初始享元模式
大家都知道围棋是啥样子的，一个棋盘，其他的是黑白两色的棋子各一盒。
两队手PK，手执一色棋，每人一步，轮流放置到棋盘不同的坐标上。
现要求大家用程序设计出一套这样的游戏，考虑下如何设计比较好。
方案1：
有个棋子的类，里面有所有属性，颜色，位置坐标等。
每次放置棋子到棋盘的时候new出一对象。
方案2：
分析该棋子的特性，发现：
棋子颜色只有两种（黑白），棋子位置一直在动态变化之中。
将颜色定义为固有属性，将位置坐标定义为外部属性。
通过有一个工厂，内部有个集合存储两种棋子（黑白），每次放置棋子到棋盘的时候从工厂中拿到对象，然后将动态坐标通过关联方式加载到棋子中。
第一种方案：
棋子对象将无休止的新增
第二种方案：
棋子对象只存在2个
2、 什么是享元模式
运用共享技术有效地支持大量细粒度的对象。
3、 模式结构图
4、模式代码事例
4、1涉及到的类，以及类图
ChessFlyWeightFactory
ConcreteChessFlyWeight
IChessFlyWeight
Point
PatternRun
4、2具体的代码实现
4、3事例输出结果
5、模式参与者
F l y w e i g h t：
IChessFlyWeight
C o n c r e t e F l y w e i g h：
ConcreteChessFlyWeight
U n s h a r e d C o n c r e t e F l y w e i g h t：
F l y w e i g h t F a c t o r y：
ChessFlyWeightFactory
OutAttribute：
Point
6、模式优缺点
A、可以避免大量相似类的开销，从而节省内存空间
B、统一管理相似类的共性，有利于维护
C、通过区分内部外部状态来处理特殊性的需求
7、模式适用性
A、一个应用程序使用了大量的对象
B、完全由于使用大量的对象，造成很大的存储开销
C、对象的大多数状态都可变为外部状态
D、如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象
E、应用程序不依赖于对象标识。
由于F l y w e i g h t对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值
-----责任链
1、初识责任链
击鼓传花是一种热闹而又紧张的饮酒游戏。
在酒宴上宾客依次坐定位置，由一人击鼓，击鼓的地方与传花的地方是分开的，以示公正。
开始击鼓时，花束就开始依次传递，鼓声一落，如果花束在某人手中，则该人就得饮酒。
比如说，贾母、贾赦、贾政、贾宝玉和贾环是五个参加击鼓传花游戏的传花者，他们组成一个环链。
击鼓者将花传给贾母，开始传花游戏。
花由贾母传给贾赦，由贾赦传给贾政，由贾政传给贾宝玉，又贾宝玉传给贾环，由贾环传回给贾母，如此往复，如下图所示。
当鼓声停止时，手中有花的人就得执行酒令。
击鼓传花便是责任链模式的应用。
责任链可能是一条直线、一个环链或者一个树结构的一部分。
2、什么是责任链模式
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
3、模式结构图
一个典型的对象结构可能如下图所示：
4、模式代码事例
场景一：
纯的责任链事例
李四生病了，去大医院看医生，他自己认为是去外科就行，结果去了后外科医生告诉他这个他医不了，让他去耳鼻科看看。
于是李四又到了耳鼻科，耳鼻科医生看了下，发现李四的病情严重了，就告诉他这个他搞不定，让他去急症科。
于是李四又到了急症科，最后急症科医好了李四的病。
场景二：
不纯的责任链事例
王五一年一次的体检来了，他先去内科体检，结束后，医生告诉他需要去外科体检。
他来到了外科，体检结束后外科医师告诉他还需要去心电图科体检。
然后他去了心电图科，心电图体检好后，就做完了所有体检项目了。
场景三：
非责任链模式
张三生病了，到了一个私人的小诊所。
医生问题是不是头疼，是不是肚子疼，帮他测量了是不是感冒，然后在诊断了下是不是咳嗽。
最后确定了他的病情，感冒了。
医生给张三开了副感冒药，张三病几天就好了。
场景一：
AbstractSickHandler：
EmergencySickHandler
GeneralSurgerySickHandler
OtolaryngologySickHandler
SimplePatternRun
场景二：
AbstractCheckUpHandler
ElectrocardiogramCheckUpHandler
MedicineCheckUpHandler
场景三：
ClinicDoctor
5、模式参与者
Handle
ConcreteHandle
Client
6、模式优缺点
1）降低耦合度该模式使得一个对象无需知道是其他哪一个对象处理其请求。
对象仅需知道该请求会被“正确”地处理。
接收者和发送者都没有对方的明确的信息，且链中的对象不需知道链的结构。
结果是，职责链可简化对象的相互连接。
它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。
2）增强了给对象指派职责（Responsibility）的灵活性当在对象中分派职责时，职责链给你更多的灵活性。
你可以通过在运行时刻对该链进行动态的增加或修改来增加或改变处理一个请求的那些职责。
你可以将这种机制与静态的特例化处理对象的继承机制结合起来使用。
3）不保证被接受既然一个请求没有明确的接收者，那么就不能保证它一定会被处理—该请求可能一直到链的末端都得不到处理。
一个请求也可能因该链没有被正确配置而得不到处理。
7、模式适用性
A、有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
B、你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
C、可处理一个请求的对象集合应被动态指定。
-----命令模式
1、初始命令模式
小时候家里面用的是黑白电视，每次想换台或者调声音大小的时候都得跑到电视边上，通过直接调电视按钮的方式来操作。
如果在大冬天，从被窝里面爬出来，换台是个痛苦的事情。
随着时代的发展，现在大家都幸福了。
都用上彩电了，每个彩电都有对应的遥控器，可以远程的通过遥控器来操作了。
这其实就是一种命令模式的体现，用户通过执行遥控器上的各个按钮命令来远程操作电视。
如：
首先，遥控器和电视是配丢的。
用户如果想调节电视声音大小，只需要按声音大小按钮。
遥控器收到这个信息，就告诉电视，让电视调整声音大小。
每一个遥控器上的按钮都是告诉电视去执行一个事情。
2、什么是命令模式
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
3、模式结构图
4、模式代码事例
场景一：
通过遥控板发命令方式控制彩色电视
场景二：
直接通过触发按钮方式控制黑白电视
4、1涉及到的类
AbstractCommand（抽象的命令）、ChangeChannelCommand，TurnDownCommand，TurnUpCommand（具体命令的实现）、Control（用于支持撤销功能）、ColorTV（接收者）、PatternRun（客户端）
4、2具体代码实现
场景一：
AbstractCommand
ChangeChannelCommand
ColorTV
Control
TurnDownCommand
PatternRun
场景二
BlackWhiteTV
NoPatternRun
4、3运行结果
5、模式参与者
命令（AbstractCommand、ChangeChannelCommand、TurnDownCommand、TurnUpCommand）
接收者（ColorTV）
触发执行者（Control）
客户端（PatternRun）
6、模式优缺点
A、支持取消（u n d o）和重做（r e d o）
7、模式适用性
A、抽象出待执行的动作以参数化某对象。
你可用过程语言中的回调（c a l l b a c k）函数表达这种参数化机制。
所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。
C o m m a n d模式是回调机制的一个面向对象的替代品。
B、在不同的时刻指定、排列和执行请求。
一个 C o m m a n d对象可以有一个与初始请求无关的生存期。
如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
C、支持取消操作。
C o m m a n d的E x c u t e操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。
C o m m a n d接口必须添加一个U n e x e c u t e操作，该操作取消上一次E x e c u t e调用的效果。
执行的命令被存储在一个历史列表中。
可通过向后和向前遍历这一列表并分别调用 U n e x e c u t e和E x e c u t e来实现重数不限的“取消”和“重做”。
D、 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。
在 C o m m a n d接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。
从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用 E x e c u t e操作重新执行它们。
E、用构建在原语操作上的高层操作构造一个系统。
这样一种结构在支持事务（ t r a n s a c t i o n ）的信息系统中很常见。
一个事务封装了对数据的一组变动。
C o m m a n d模式提供了对事务进行建模的方法。
C o m m a n d有一个公共的接口，使得你可以用同一种方式调用所有的事务。
同时使用该模式也易于添加新事务以扩展系统。
-----中介者
1、初识中介者
那些年，我们一起上过的大学，班级里有班长，有团书记。
想一想如果没有QQ这种通讯工具的话，那么班长或者团支书该怎样下达消息呢？
？
同时，班级上两个同学之间也可惜沟通啊，沟通一下，院里哪个女生，哪个帅哥呀~~~如果没有QQ的话，大概就是下面的情景：
哎呀呀，看看这个乱那。
如果同学的数目多起来就会变成网状的结构啦。
原本把一个系统分割成一些对象是可以增强复用性的，但是现在的情况是，这些兑现之间存在着大量的联系，耦合性极高。
这是很不利于复用的，同时这种情况使得系统的灵活性大大的降低，使得对系统的扩展很难，要是新转来一个学生的话，要改动的地方就多了去了。
如果现在可以使用QQ，那么可以采用另一种方式设计这个系统呢，比如做成星形的结构：
看看这种“星形结构”和“网状结构”的区别吧，显然采用星形结构就可以避免上面的网状结构存在的问题了，实际上这里的QQ就是指的是中介，这样一来每个学生对象就不用存在耦合了，同学之间需要交流可以通过一个QQ群。
2、什么是中介者
用一个中介对象来封装一系列的对象交互。
中介者使各对象不需要显式地相互引用，从
而使其耦合松散，而且可以独立地改变它们之间的交互。
3、模式结构图
4、模式代码事例
场景：
新年快到了，公司要给每位员工送年货。
当然，公司不可能直接消耗人力资源自己往每个员工家里送物品，所以收集了每个员工的一些信息，通过快递公司为其送出物品。
4、1涉及到的类，以及类图
ExpressMediator（抽象的中介者）、EMSExpressMediator（具体的中介者EMS快递）、Colleage（抽象的同事类）、Company（具体的同事类公司）、Person（具体的同事类员工）
4、2具体的代码实现
ExpressMediator（抽象的中介者）
EMSExpressMediator（具体的中介者EMS快递）
Colleage（抽象的同事类）
Company（具体的同事类公司）
Person（具体的同事类员工）
4、3事例输出结果
5、模式参与者
中介者（Mediator，如：
ExpressMediator）
具体中介者（ConcreteMediator，如EMSExpressMediator）
同事类（Colleague，如Company、Person）
6、模式优缺点
A、减少了子类生成
升级会员 