设计模式概述

本文由 @lonelyrains出品，文章链接： http://blog.csdn.net/lonelyrains/article/details/51089534

• 那么多所谓的设计模式，为什么老是记不住？
• 为什么面试的时候总是回答不上来？
• 其实本来很简单的内容，为什么很难在实际项目中使用？

面试的时候，考察设计模式，就像是“天王盖地虎，宝塔镇河妖”一样的黑话。在道上混，虽然不知道会碰到什么鬼神，知道内涵意义的同时，也需要知道这些形式上的东西到底是怎么一一表述的。不然，咋死的都不知道~

• 设计模式的性质 
  
  • 都是一些特定使用场景的固定章法
• 设计模式的实现 
  
  • 都是加抽象层
• 设计模式的目的 
  
  • 都是解耦
  • 评价是否是过度设计：被解耦的部分是否确实可能频繁变化

对一些常用的设计模式套用上面的描述结构：

创建型

工厂模式(Factory)

• 性质 
  
  • 创建型场景的固定章法。
• 实现 
  
  • 创建对象时加一层抽象，相对于直接调用创建指定对象的代码而言。
  • 所有的创建都被封装在一种叫指定对象工厂的代码里。
• 目的 
  
  • 针对的是解耦一种类型的特定对象创建。创建特定对象的代码可能会频繁变化。

抽象工厂(Abstract Factory)

• 性质 
  
  • 创建型场景的固定章法。
• 实现 
  
  • 创建对象时加一层抽象，相对于直接调用创建指定对象的工厂方法而言。
  • 所有的创建都被封装在一种叫抽象对象工厂的代码里。
• 目的 
  
  • 针对的是解耦特定类型的对象创建。创建对象的类型可能频繁变化。

结构型

桥接(Bridge)

• 性质 
  
  • 结构型场景的固定章法。结构型是经常需要重构的部分。
• 实现 
  
  • 接口和实现加一层抽象，相对于直接调用特定功能实现。
  • 所有的特定功能实现都被封装在一种叫特定实现接口的代码里。
  • 其实将实现当做特定对象的话，桥接就跟工厂模式没什么区别。工厂这时候就是接口。
• 目的 
  
  • 针对的是解耦特定类型的功能调用。实现特定类型功能的方法可能频繁变化。
• 思考 
  
  • 为什么没有对应的抽象桥接模式？因为抽象桥接如果存在，需要解耦的部分就是特定类型的功能接口。也就是说在调用这个类时，不知道需要调用其中的什么方法。这种使用场景虽然不是没有，但是极其少见，所以没有这个提法而已。其他设计模式为什么没有对应的抽象XXX设计模式，也是因为这个原因。“抽象”两个字就像是运算符，本可以无限往上叠加。比如，抽象抽象工厂模式是不是可以存在呢？因为没有解耦的实际意义，所以并不存在实用价值。

装饰模式(Decorator)

• 性质 
  
  • 结构型场景的固定章法。
• 实现 
  
  • 调用特定对象的功能组合时，加多一层抽象，相对于直接定义并调用多变功能的子类对象而言。
• 目的 
  
  • 将额外功能可以通过不同子类组合起来，而不是笨拙地拼接定义新子类。功能定制更加灵活。

行为型

模板方法(TemplateMethod)

• 性质 
  
  • 行为型场景的固定章法。
• 实现 
  
  • 增加一层调用算法流程的骨架，在父类中定义好。注意这个骨架是不变的部分。各种子类实现里实现这个算法流程骨架函数里的具体调用子函数。可想而知，这个通用算法流程骨架函数通常不需要是虚函数，而子函数需要。
• 目的 
  
  • 仅仅是为了减少骨架方法每个子类都实现一遍的重复劳动，没啥玄乎的。

观察者模式(Observer)

• 性质 
  
  • 行为型场景的固定章法。
• 实现 
  
  • 通过增加定义一层抽象观察者类，在需要观察的类结构里增加一层消息通知的机制。对所有需要对此类对象状态变化产生行为的各种观察者进行统一通知。
• 目的 
  
  • 实现统一通知，解耦的是各种自定义类、五花八门的通知方式。

总结

本文通过对创建、结构、行为型三种设计模式中分别提取两种典型的设计模式加以探讨，得出一个基本的设计模式的理解骨架——即从性质（使用场景）、实现（如何解耦）、目的（解耦什么）三方面考察，然后附加一点自己的思考。

这个总结本身也是一种抽象。理解有偏差的地方，或者有不同的声音，欢迎一起探讨或者指正。