代码架构--设计模式概述

前言

“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中，意在搭建扎实的建筑基础，解决日常或突发的房屋设计问题。现在狭义的“设计模式”被广泛应用于软件设计领域，它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

何为设计模式

如上文介绍，软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
总的来说，设计模式就是前人的总结的一套写好代码的方法。就像是学霸告诉你的解题技巧，能够更快更漂亮的解出题目。通过对它的学习可以让我们更好的从日常业务中抽象出来，提升软件架构及设计能力，并反哺业务。

设计模式解决问题的设计原则

为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，前人总结了7条设计原则，从以上方面进行代码框架的思考，从而提高软件开发效率、节约软件开发成本和维护成本。

• 开闭原则（Open Close Principle，COP）
  开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求
  也就是说，开闭原则的衡量标准是: 当需要增加新的功能项时，是否能不修改已有的代码，只需要增加新的类或方法就可能实现。同样的，在进行功能测试时，只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。
  总之就是程序扩展功能容易，不用修改原有代码就能实现需求。一般是采用接口以及抽象类的方式去实现的，就像Spring中，替换Service实现类，是通过修改注解或配置来实现，不用修改代码。
  【案例】Windows 的桌面主题设计。
  【分析】：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的，其类图如图所示。
  

• 里氏代换原则（Liskov Substitution Principle LSP）

  里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
  里氏替换原则是实现开闭原则的重要方式之一。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

  根据上述理解，对里氏替换原则的定义可以总结如下：

  1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
  2. 子类中可以增加自己特有的方法
  3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
  4. 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等

  通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
  【案例】几维鸟不是鸟
  【分析】鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。但是新西兰的几维鸟由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”，明显不符合预期。
  程序运行错误的原因是：几维鸟类重写了鸟类的 setSpeed(double speed) 方法，这违背了里氏替换原则。正确的做法是：取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0，可以计算出其奔跑 300 千米所要花费的时间。

• 依赖倒转原则（Dependence Inversion Principle）

  这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。就比如我们使用Spring编写web应用，service和dao的使用，都是通过接口来调用，一旦我们需要变更实现方法，我们只需要变更注入的实现类，就可以替换代码，而不是像直接调用实现类那样，一旦变更，就需要修改以前的代码。

• 单一职责原则（Single Responsibility Principle，SRP）
  这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分
  该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

  1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
  2. 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

  【案例】：大学学生工作管理程序。
  【分析】：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做 法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图所示。

  大学学生工作管理程序的类图
  
  注意：单一职责同样也适用于方法。一个方法应该尽可能做好一件事情。如果一个方法处理的事情太多，其颗粒度会变得很粗，不利于重用。

• 接口隔离原则（Interface Segregation Principle）

  这个原则的意思是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。就比如我们在web中经常会使用的BaseDao这个类，里面会有增删查改四个基本方法，但其实增删查改复杂之后，可能会有多种方法，这个时候把增删查改进行拆分，变成4个接口，再由BaseDao继承，会更好管理。

• 迪米特法则（最少知道原则）（Demeter Principle）
  为什么叫最少知道原则，就是说：其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。这也是当前微服务所提倡的一点，要保证服务的独立，自治性。
  【案例】：明星与经纪人的关系实例。
  【分析】：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，

• 合成复用原则（Composite Reuse Principle）
  它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
  如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
  注：总的来说，其实就是高内聚，低耦合。通过面向接口编程，降低模块间的耦合，相互独立，提高代码的扩展性。
  合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

  【案例】：汽车分类管理
  【分析】：汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。

23 种设计模式的分类和功能

根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。后续将针对这三种设计模式进行详细的分析。

• 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
• 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
• 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。