【设计模式总结篇】

前言：

学习设计模式已经将近一个月了，与大话设计模式之相处日渐之深，此篇博客是对大话设计模式的一个总结，为自己留下一个学习的脚步！本文从设计模式的三个类别进行总结，对每个设计模式的定义，使用场合，关键字几个方面来介绍。当然，少不了设计模式的原则。

内容：

（一）设计模式之全局

设计模式按照目的，可分为创建型、行为型、结构型三个类别。

<>创建型模式:

抽象了实例化的过程，它帮助系统独立于创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。
总结·考虑对象的实例化过程

<>结构型模式：

分为类和对象，采用继承机制来组合接口或实现，这是类创建型模式；通过聚合或依赖一些对象，从而实现新的功能，这是对象创建型模式。
总结·考虑如何组合类和对象以获得更大的结构

<>行为型模式：

行为型模式描述类或对象以及它们之间如何交互及如何分配职责，它 主要涉及通过合理的处理方法，达到使系统升级性和维护性提高的目的。行为类模式使用继承机制，行为对象模式使用对象复合。
总结·考虑算法和对象职责的分配

(二)具体

创建型模式：5

*抽象工厂模式：

定义：

提供一个创建一系列或相关依赖对象的接口，而无需指定他们具体的类
不直接通过对象的具体实现类，而是通过使用专门的类来负责一组相关联的对象的创建。

使用场合：

1）系统不依赖于产品是如何实现的细节；

2）系统的产品族大于1，而在运行时刻只需要某一种产品族；

3）属于同一个产品族的产品，必须绑在一起使用；

4）所有的产品族，可以抽取公共接口

总结：创建接口

*建造者模式：

定义：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
将一个类的创建过程和他的主体部分分离。
使用场合

是在当创建对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。

总结：构建与表示分离。

*工厂方法模式：

定义：

一个用于创建对象的借口，让子类决定实例化哪一个类，工厂模式使一个类的实例化延迟到子类
Factory Method的主要思想是使一个类的实例化延迟到其子类。

使用场合：

1）类不知道它所要创建的对象的类信息；

2）类希望由它的子类来创建对象。

总结：创建对象接口，子类实例化

*原型模式：

定义：

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
克 隆一个已有的类的实例

使用场合：

1）系统不关心对象创建的细节；

2）要实例化的对象的类型是动态加载的；

3）类在运行过程中的状态是有限的。

总结：拷贝原型创建新对象

*单例模式：

定义：

保障一个类只有一个实例，并提供一个访问它的全局访问点
保证一个类只有一个唯一的实例

使用场合：

各种“工厂类” 

总结：一类一实例，全局访问点        

结构型模式 7

*适配器：

定义：

将一个类的接口转换成客户希望的另外一个接口

使用场合：

软件开发后期和维护期：使用一个已经存在的类，但如果它的接口，也就是它的方法和你的要求不相同时
 

总结：转换接口

*桥接模式：   

定义：

将抽象部分和它的实现部分分离，使他们都可以独立变化
将一个类的抽象定义和具体实现解耦。
  使用场合：

1）系统需要在组件的抽象化角色与具体化角色之间增加更多的灵活；

2）角色的任何变化都不应该影响客户端；

3）组件有多个抽象化角色和具体化角色

总结：抽象与实现相分离

*组合模式： 

定义：

将对象组合成树形结构以表示部分-整体的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性
   使用场合：

需求中是体现部分和整体层次的结构时，以及你希望用户忽略组合对象与单个对象的不同，统一地使用这回结构中的所有对象时。
  总结：部分—整体层次结构

*装饰模式: 

定义：

动态的 给一个对象添加一些额外的职责，就增加功能来说，装饰模式相比生成子类更加灵活
  使用场合

1）需要添加对象职责；

2）这些职责可以动态添加或者取消；

3）添加的职责很多，从而不能用继承实现。

总结：

动态添加职责

*外观模式： 

定义：

为子类系统中 的一组接口提供一个一致的界面外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
。 

使用场合：

三个阶段： 

设计初期阶段：应该要有意识将两个不同的层分离，比如经典的三层架构，需要考虑，层与层之间建立外观，提供接口，降低耦合，
开发阶段：子系统因不断重构演化而变复杂，增加外观，提供接口，减少依赖
维护阶段：当老系统难以维护和扩展时，增加外观，新系统与外观对象交互，减少麻烦
  总结：为界面提供高层接口

*享元模式：  

定义：

运用共享技术有效的支持大量细粒度的对象
   使用场合：

如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储可以用相对较少的共享对象取代很多组对象；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象
。 

总结：

共享支持对象

*代理模式： 

定义：

为其他对象提供一种代理以控制对这个对象的访问
使用场合：

远程代理
   虚拟代理
安全代理

智能代理

总结：

代理访问对象

行为型模式 11

*模板方法模式： 

定义：

定义一个操作算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变算法的结构即可 重定义改算法的某些特定步骤
  使用场合：

使用当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为在子类中重复出现
  总结：

定义算法骨架，步骤延迟子类

   *命令模式： 

定义：

将一个请求封装为一个对象，从而使你可用不同 的请求对客户进行参数化，可以对请求排队或记录日志，以及支持可撤销的操作。
  使用场合：

1）调用者同时和多个执行对象交互；

2）需要控制调用本身的生命周期；

3）调用可以取消

总结：封装请求为对象，利用请求参数化

*状态模式： 

定义：

允许一个对象在其内部状态改变时改变他的行为，让对象看起来似乎修改了它的类
  使用场合：

当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑状态模式了
  总结：状态改变，改变行为

*职责链模式：  

定义：

使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系，将这些对象连成一条线，并沿着这条链传递该请求，直到有一个对象处理它为止 

使用场合：

1）输入对象需要经过一系列处理；

2）这些处理需要在运行时指定；

3）需要向多个操作发送处理请求；

4）这些处理的顺序是可变的

总结：

发送者和接收者连成一条线，直到处理

*解释器模式：  

定义：

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
  使用场合：

当有一个语言需要解释执行，并且可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。
  总结：

定义语言文法，定义解释器

*中介者模式： 

定义：

用一个中介者来封装一系列对象的交互。中介者使个对象不需要显示的相互吸引，从而使其耦合松散，而且可以独立 的改变他们之间的交互
  使用场合：

中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想要定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。
  总结：

封装对象交互，解耦和 

*访问者模式： 

定义：

表示作用于某个对象结构中的各个元素的操作，他使你可以在不改变个元素类的前提下定义作用于这些元素的新操作
  使用场合：

系统有比较的数据结构，又有易于变化的算法。
  总结：

定义对象结构新操作

*策略模式：  

定义：

定义一系列的算法，把他们一个个封装起来，并且使他们可相互替换。本模式使得算法可独立于使用它的客户而变化
  使用场合：

1）完成某项业务有多个算法；

2）算法可提取公共接口

总结：

定义算法，进行封装，相互替换

*备忘录模式： 

定义:

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态
  使用场合：

1）对象的属性比较多，但需要备份恢复的属性比较少；

2）对象的状态是支持恢复的

总结：

捕获内部状态，进行保存

*迭代器模式：  

定义：

提供一种方法顺序访问一个聚合对象中各个元素，而又不需要暴露该对象的内部表示

   使用场合：

1）访问一个聚合对象的内容，而不必暴露其内部实现；

2）支持对聚合对象的多种遍历方式；

3）为遍历不同的聚合对象提供一致的接口

总结：顺序访问对象元素，不暴露对象内部

（三）六原则

详细见博客：设计模式六原则：点击打开链接

总结：

设计模式的运用，使得代码易复用、更灵活让代码更容易被他人理解，保证代码的可靠性。 设计模式的学习，这是一个阶段的学习，以后的学习过程中还会继续学习，温故知新，这就是学习。如果有问题的地方，希望与大家交流，提出宝贵意见。