设计模式笔记(25)—总结

断断续续经历了几个月的时间将WebCast的设计模式讲座重新完整听了一遍,并做了笔记,才有了这个设计模式笔记系列,本系列的文章大部分只是给出了基本代码的实现,而并没有去衍生其他的一些例子,笔者认为通过基本的代码实现就能够了解到模式的应用场景,弄出些花哨的例子反倒会让人眼花缭乱,可能并达不到预期的效果,毕竟在实际的应用中我们不是去套用模式。本文作为该系列的最后一篇,将对设计模式做个总结。

首先看下创建型、结构型、行为型这三种类型的模式的解释

创建型

  • Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。
  • Factory Method, Abstract Factory, Builder都需要一个额外的工厂类来负责实例化“易变对象”,而 Prototype则是通过原型 (一个特殊的工厂类)来克隆“易变对象”。
  • 如果遇到“易变类”,起初的设计通常从FactoryMethod开始,当遇到更多的复杂变化时,再考虑重构为其他三种工厂模式 (Abstract Factory 、Builder 、Prototype )。

结构型

  • Adapter模式注重转换接口,将不吻合的接口适配对接。
  • Bridge模式注重分离接口与其实现,支持多维度变化。
  • Composite模式注重统一接口,将“一对多”的关系转化为“一对一”的关系。
  • Decorator模式注重稳定接口,在此前提下为对象扩展功能。
  • Façade模式注重简化接口,简化组件系统与外部客户程序的依赖关系。
  • Flyweight 模式注重保留接口,在内部使用共享技术对对象存储进行优化。
  • Proxy 模式注重假借接口,增加间接层来实现灵活控制。

行为型

  • Template Method模式封装算法结构,支持算法子步骤变化。
  • Strategy模式注重封装算法,支持算法的变化。
  • State模式注重封装与状态相关的行为,支持状态的变化。
  • Memento模式注重封装对象状态变化,支持状态保存/恢复。
  • Mediator模式注重封装对象间的交互,支持对象交互的变化。
  • Chain Of Responsibility模式注重封装对象责任,支持责任的变化。
  • Command模式注重将请求封装为对象,支持请求的变化。
  • Iterator 模式注重封装集合对象内部结构,支持集合的变化。
  • Interpreter模式注重封装特定领域变化,支持领域问题的频繁变化。
  • Observer模式注重封装对象通知,支持通信对象的变化。
  • Visitor模式注重封装对象操作变化,支持在运行时为类层次结构动态添加新的操作。

设计模式应用总结

  • 设计模式建立在对系统变化点的基础上进行,哪里有变化点,哪里应用设计模式。
  • 设计模式应该以演化的方式来获得,系统的变化点往往是经过不断演化才能准确定位。
  • 不能为了模式而模式,设计模式是一种软件设计的软力量,而非规范标准。不应夸大设计模式的作用。

上面的大部分内容都为讲座中的内容,并没有做更多的改动,因为那些概况已经非常简明扼要。软件发展到今天,可以说远远不止这23中模式,只是常常被大家所提及的是这23中经典而已。这些模式的提出时因为软件的需求总是在发生变化,如果说不存在需求的变化,那么设计模式也就没有存在的必要了。这种情况是不可能存在,所以为了在需求变化的时候能够很好的应对,提供代码复用,降低成本就需要应用设计模式。所以说设计模式并不是在软件设计之初就存在,而是随着需求的变化一步一步重构而来的。

设计模式虽然很多,但万变不离其宗,不管怎么变都脱离不了5大设计原则(SRP OCP LSP DIP ISP),掌握了这五大设计原则,勤思考多实践,那么在项目中遇到变化时就可以灵活运行设计模式了。

返回开篇(索引)