设计模式 · 总(理论)

一、面向对象设计原则

1.概述

1.1 可维护性、复用性较低的原因

• 过于僵硬(Rigidity)
• 过于脆弱(Fragility)
• 复用率低(Immobility)
• 黏度过高(Viscosity)

1.2 好的系统设计应该具备三大性质

• 可扩展性(Extensibility)
• 灵活性(Flexibility)
• 可插入性(Pluggability)

1.3 设计原则和设计模式是对系统进行合理重构的指南针

重构(Refactoring)是在不改变软件现有功
能的基础上(业务功能不变)，通过调整程序代码改善软件的质量、性能，
使其程序的设计模式和架构更趋合理，提高软件的扩展
性和维护性。

2.单一职责原则 ★★★★

2.1.定义

• 单一职责原则(Single Responsibility Principle, SRP)定义如下：
  • 一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类
    中。
• 另一种定义方式如下：
  • 就一个类而言，应该仅有一个引起它变化的原因。

2.2 分析

• 一个类（或者大到模块，小到方法）承担的职责越多，它被复用的
  可能性越小，而且如果一个类承担的职责过多，就相当于将这些职
  责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运
  作。
• 类的职责主要包括两个方面：数据职责和行为职责，数据职责通过
  其属性来体现，而行为职责通过其方法来体现。
• 单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构
  手法中都能找到它的存在，它是最简单但又最难运用的原则，需要
  设计人员发现类的不同职责并将其分离，而发现类的多重职责需要
  设计人员具有较强的分析设计能力和相关重构经验。

2.3 实例

3.开闭原则 ★★★★★

3.1 定义

• 一个软件实体应当对扩展开放，对修改关闭。也就是说在设计
  一个模块的时候，应当使这个模块可以在不被修改的前提下被
  扩展，即实现在不修改源代码的情况下改变这个模块的行为。

3.2 分析

软件实体可以指一个软件模块、
一个由多个类组成的局部结构或一个独立的类。

• 抽象化是开闭原则的关键。
• 开闭原则还可以通过一个更加具体的“对可变性封
  装原则”来描述，对可变性封装原则(Principle of
  Encapsulation of Variation, EVP)要求找到系统
  的可变因素并将其封装起来。

3.3 实例

4.里氏代换原则 ★★★★

4.1 定义

• 里氏代换原则(Liskov Substitution Principle, LSP)有两种定义方式，
  第一种定义方式相对严格，其定义如下：
  • 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有
    程序P在所有的对象o2都代换成o1时，程序P的行为没有变化，那么类型S是类
    型T的子类型。
• 第二种更容易理解的定义方式如下：
  • 所有引用基类（父类）的地方必须能透明地使用其子类的对象。

4.2 分析

• 里氏代换原则可以通俗表述为：在软件中如果能够使用
  基类对象，那么一定能够使用其子类对象。把基类都替
  换成它的子类，程序将不会产生任何错误和异常，反过
  来则不成立，如果一个软件实体使用的是一个子类的话，
  那么它不一定能够使用基类。
• 里氏代换原则是实现开闭原则的重要方式之一，由于使
  用基类对象的地方都可以使用子类对象，因此在程序中
  尽量使用基类类型来对对象进行定义，而在运行时再确
  定其子类类型，用子类对象来替换父类对象。

4.3 实例

• 如果需要更换一个加密算法类或者增加并使用一个新的加密算
  法类，如将CipherA改为CipherB，则需要修改客户类Client和数
  据操作类DataOperator的源代码，违背了开闭原则。

• 现使用里氏代换原则对其进行重构，使得系统可以灵活扩展，
  符合开闭原则。

5.依赖倒转原则[DIP] ★★★★★

5.1 定义

• 依赖倒转原则(Dependence Inversion Principle, DIP)的定义
  如下：
  • 高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依
    赖于细节，细节应该依赖于抽象。
• 另一种表述为：
  • 要针对接口编程，不要针对实现编程。(Program to an interface, not an implementation.)

依赖倒置=控制反转[理论] -> 依赖注入[实现]

DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

• 谁依赖于谁：当然是应用程序依赖于IoC容器；
• 为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
• 谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
• 注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

IoC[ ++控制反转 Ioc - Inversion of Control++ ]和DI[ ++依赖注入 DI - Dependency Injection++ ]关系：

其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

个人感觉依赖注入是强调实现,控制反转是强调概念。

• 依赖注入
  • 构造注入(Constructor Injection)：通过构造函数注
    入实例变量。
  • 设值注入(Setter Injection)：通过Setter方法注入实
    例变量。
  • 接口注入(Interface Injection)：通过接口方法注入
    实例变量。

5.2 分析

• 依赖倒转原则: 代码要依赖于抽象的
  类，而不要依赖于具体的类；要针对接口或抽象类编程，
  而不是针对具体类编程。
• 实现开闭原则的关键是抽象化，并且从抽象化导出具体
  化实现，如果说开闭原则是面向对象设计的目标的话，
  那么依赖倒转原则就是面向对象设计的主要手段。

依赖倒转原则的常用实现方式之
一是在代码中使用抽象类[接口]，而将
具体类放在配置文件中。

• “将抽象放进代码，将细节放进元数
  据”

类之间的耦合

• 零耦合关系(不可能)
• 具体耦合关系(扩展不友好)
• 抽象耦合关系

依赖倒转原则要求客户端依赖于抽象耦合，++以抽象方式耦合是依赖倒转原则的关键++。

5.3 实例

通过依赖注入[反射技术]来实现依赖倒置原则。

由于需求的变化，该系统可能需要增加新的数据源或者
新的文件格式，每增加一个新的类型的数据源或者新的
类型的文件格式，客户类MainClass都需要修改源代码，
以便使用新的类，但违背了开闭原则。现使用依赖倒转
原则对其进行重构。

6.接口隔离原则 ★★

6.1 定义

• 接口隔离原则(Interface Segregation Principle, ISP)的定义如下：
  • 客户端不应该依赖那些它不需要的接口[方法]。
• 注意，在该定义中的接口指的是所定义的方法。
• 另一种定义方法如下：
  • 一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接
    口的客户端仅需知道与之相关的方法即可。

6.2 分析

• 接口隔离原则是指使用多个专门的接口，而不使用单
  一的总接口。每一个接口应该承担一种相对独立的角
  色，不多不少，不干不该干的事，该干的事都要干。
  • (1) 一个接口就只代表一个角色，每个角色都有它特定的一个
    接口，此时这个原则可以叫做“角色隔离原则”
    。
  • (2) 接口仅仅提供客户端需要的行为，即所需的方法，客户端
    不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独
    的接口，而不要提供大的总接口。
• 使用接口隔离原则拆分接口时，首先必须满足单一职
  责原则，将一组相关的操作定义在一个接口中，且在
  满足高内聚的前提下，接口中的方法越少越好。
• 可以在进行系统设计时采用定制服务的方式，即为不
  同的客户端提供宽窄不同的接口，只提供用户需要的
  行为，而隐藏用户不需要的行为。

6.3 实例

• 使用接口隔离原则重构

7.合成复用原则 ★★★★

7.1 定义

• 合成复用原则(Composite Reuse Principle, CRP)又称为组合/
  聚合复用原则(Composition/ Aggregate Reuse Principle,
  CARP)，其定义如下：
  • 尽量使用对象组合，而不是继承来达到复用的目的。
• 合成复用原则就是指在一个新的对象里通过关联关系
  （包括组合关系和聚合关系）来使用一些已有的对象，
  使之成为新对象的一部分；新对象通过委派调用已有
  对象的方法达到复用其已有功能的目的。简言之：要
  尽量使用组合/聚合关系，少用继承。

7.2 分析

• 在面向对象设计中，可以通过两种基本方法在不同的
  环境中复用已有的设计和实现，即通过组合/聚合关系
  或通过继承。
  • 继承复用：实现简单，易于扩展。破坏系统的封装性；从基类
    继承而来的实现是静态的，不可能在运行时发生改变，没有足
    够的灵活性；只能在有限的环境中使用。（“白箱”复用 ）
  • 组合/聚合复用：耦合度相对较低，选择性地调用成员对象的
    操作；可以在运行时动态进行。（“黑箱”复用 ）
• 首选使用组合/聚合来实现复用；其次才考虑
  继承，在使用继承时，需要严格遵循里氏代换原则。滥用继承反而会增加系统构建和维护的难度以及系
  统的复杂度，因此需要慎重使用继承复用。

7.3 实例

• 如果需要更换数据库连接方式，如原来采用JDBC连接数据库，
  现在采用数据库连接池连接，则需要修改DBUtil类源代码。如
  果StudentDAO采用JDBC连接，但是TeacherDAO采用连接池
  连接，则需要增加一个新的DBUtil类，并修改StudentDAO或
  TeacherDAO的源代码，使之继承新的数据库连接类，这将违
  背开闭原则，系统扩展性较差。
• 现使用合成复用原则对其进行重构。

8.迪米达法则 ★★★

8.1 定义

• 迪米特法则(Law of Demeter, LoD)又称为最少知识原则(Least
  Knowledge Principle, LKP)，它有多种定义方法，其中几种典
  型定义如下：
  • (1) 不要和“陌生人”说话。
  • (2) 只与你的直接朋友通信。
  • (3) 每一个软件单位对其他的单位都只有最少的知识，而且局限于那
    些与本单位密切相关的软件单位。

8.2 分析

• 迪米特法则就是指一个软件实体应当尽可
  能少的与其他实体发生相互作用。当一个模块
  修改时，就会尽量少的影响其他的模块，扩展会相对
  容易，这是对软件实体之间通信的限制，它要求限制
  软件实体之间通信的宽度和深度。
• 在迪米特法则中，对于一个对象，其朋友包括以下几类：
  • (1) 当前对象本身(this)；
  • (2) 以参数形式传入到当前对象方法中的对象；
  • (3) 当前对象的成员对象；
  • (4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是
    朋友；
  • (5) 当前对象所创建的对象。
• 任何一个对象，如果满足上面的条件之一，就是当前对象的“朋
  友”
  ，否则就是“陌生人”
  。

狭义与广义

• 狭义的迪米特法则：可以降低类之间的耦合，但是会在系统中增加大量
  的小方法并散落在系统的各个角落，它可以使一个系统的局部设计简化，
  因为每一个局部都不会和远距离的对象有直接的关联，但是也会造成系
  统的不同模块之间的通信效率降低，使得系统的不同模块之间不容易协
  调。
• 广义的迪米特法则：指对对象之间的信息流量、流向以及信息的影响的
  控制，主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间脱
  耦，从而允许它们独立地被开发、优化、使用和修改，同时可以促进软
  件的复用，由于每一个模块都不依赖于其他模块而存在，因此每一个模
  块都可以独立地在其他的地方使用。一个系统的规模越大，信息的隐藏
  就越重要，而信息隐藏的重要性也就越明显。

迪米特法则的主要用途在于控制信息的过载：

• 在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越
  低，就越有利于复用，一个处在松耦合中的类一旦被修改，不
  会对关联的类造成太大波及；
• 在类的结构设计上，每一个类都应当尽量降低其成员变量和成
  员函数的访问权限；
• 在类的设计上，只要有可能，一个类型应当设计成不变类；
• 在对其他类的引用上，一个对象对其他对象的引用应当降到最
  低。

8.3 实例

• 迪米特法则重构
  

9.总结

• 单一职责原则要求在软件系统中，
  一个类只负责一个功能
  领域中的相应职责。
• 开闭原则要求一个软件实体应当对扩展开放，对修改关闭，
  即在不修改源代码的基础上扩展一个系统的行为。
• 里氏代换原则可以通俗表述为在软件中如果能够使用基类
  对象，那么一定能够使用其子类对象。
• 依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖
  于抽象；要针对接口编程，不要针对实现编程。
• 接口隔离原则要求客户端不应该依赖那些它不需要的接口，
  即将一些大的接口细化成一些小的接口供客户端使用。
• 合成复用原则要求复用时尽量使用对象组合，而不使用继
  承。
• 迪米特法则要求一个软件实ss体应当尽可能少的与其他实体
  发生相互作用。

二、设计模式

1.设计模式的诞生与发展

1.0 模式的诞生

• 模式起源于建筑业而非软件业
• 模式(Pattern)之父——美国加利佛尼亚大学环境结构中心研究所
  所长Christopher Alexander博士
• 模式
  • Context（模式可适用的前提条件）
  • Theme或Problem（在特定条件下要解决的目标问题）
  • Solution（对目标问题求解过程中各种物理关系的记述）
• 定义:
  • A pattern is a solution to a problem in a context [ 模式是在特定环境中解决问题的一种方案 ]
  • Alexander给出了关于模式的经典定义：每个模式都描
    述了一个在我们的环境中不断出现的问题，然后描述了
    该问题的解决方案的核心，通过这种方式，我们可以无
    数次地重用那些已有的解决方案，无需再重复相同的工
    作。

1.1 软件中的诞生

最早将
该模式的思想引入软件工程方法学的是1991-1992年以“四
人组(Gang of Four，GoF，分别是Erich Gamma,
Richard Helm, Ralph Johnson和John Vlissides)”自称
的四位著名软件工程学者，他们在1994年归纳发表了23种
在软件开发中使用频率较高的设计模式，旨在用模式来统一
沟通面向对象方法在分析、设计和实现间的鸿沟。

1.2 软件模式

• 软件模式是将模式的一般概念应用于软件开发领域，即软件开发的
  总体指导思路或参照样板。++软件模式++并非仅限于设计模式，++还包括
  架构模式、分析模式和过程模式等++，实际上，在软件生存期的每一
  个阶段都存在着一些被认同的模式。
• 软件模式可以认为是对软件开发这一特定“问题”的“解法”的某
  种统一表示，它和Alexander所描述的模式定义完全相同，即软件
  模式等于一定条件下的出现的问题以及解法。软件模式的基础结构
  由4个部分构成：问题描述、前提条件（环境或约束条件）、解法
  和效果。
• 软件模式与具体的应用领域无关，在模式发现过程中需
  要遵循大三律(Rule of Three)，即只有经过三个以上
  不同类型（或不同领域）的系统的校验，一个解决方案
  才能从候选模式升格为模式。

1.3 设计模式的发展

• 1987年，Kent Beck和Ward Cunningham借鉴Alexander的模式思想
  在程序开发中开始应用一些模式 ，在OOPSLA会议上发表了他们的成果。
• 1990年，OOPSLA与ECOOP联合举办，Erich Gamma和Richard Helm
  等人开始讨论有关模式的话题(Bruce Anderson主持)，
  “四人组” 正式
  成立，并开始着手进行设计模式的分类整理工作。
• 1991 年，OOPSLA，Bruce Anderson主持了首次针对设计模式的研讨
  会 。
• 1992 年，OOPSLA ，Anderson再度主持研讨会，模式已经逐渐成为人
  们讨论的话题。
  • 注: OOPSLA (Object-Oriented Programming, Systems, Languages
    & Applications，面向对象编程、系统、语言和应用大会)，编程语言及
    软件工程国际顶级会议，2010年改为SPLASH — Systems,
    Programming, Languages and Applications: Software for
    Humanity
• 1993年，Kent Beck 和 Grady Booch 赞助了第一次关于设计模式的会
  议，这个设计模式研究组织发展成为著名的Hillside Group研究组。
• 1994 年，由Hillside Group发起，在美国伊利诺伊州(Illinois)的
  Allerton Park召开了第1届关于面向对象模式的世界性会议，名为
  PLoP(Pattern Languages of Programs, 编程语言模式会议)，简称
  PLoP‘94。
• 1995年，PLoP‘95 仍在伊利诺伊州的Allerton Park举行 ，
  “四人组”
  出版了《设计模式：可复用面向对象软件的基础》(Design Patterns:
  Elements of Reusable Object-Oriented Software)一书，本书成为
  1995年最抢手的面向对象书籍，也成为设计模式的经典书籍。

2.设计模式的定义与分类

2.0 定义

• 设计模式(Design Pattern)是一套被反复使用、多数人
  知晓的、经过分类编目的、代码设计经验的总结。使用
  设计模式是为了可重用代码、让代码更容易被他人理解、
  保证代码可靠性。
• 设计模式一般有如下几个基本要素：模式名称、问题、
  目的、解决方案、效果、实例代码和相关设计模式，其
  中的关键元素包括以下四个方面：
  • 模式名称 (Pattern name)
  • 问题 (Problem)
  • 解决方案 (Solution)
  • 效果 (Consequences)

2.1 目的分类

根据其目的（模式是用来做什么的）可分为创建型
(Creational)，结构型(Structural)和行为型
(Behavioral)三种：

• 创建型模式主要用于创建对象。
• 结构型模式主要用于处理类或对象的组合。
• 行为型模式主要用于描述对类或对象怎样交互和怎
  样分配职责。

2.2 范围分类

根据范围，即模式主要是用于处理类之间关系还是处理
对象之间的关系，可分为类模式和对象模式两种：

• 类模式处理类和子类之间的关系，这些关系通过继承建立，
  在编译时刻就被确定下来，是属于静态的。
• 对象模式处理对象间的关系，这些关系在运行时刻变化，
  更具动态性。

3.GoF设计模式简介

• 创建型模式

1. 抽象工厂模式(Abstract Factory)
2. 建造者模式(Builder)
3. 工厂方法模式(Factory Method)
4. 原型模式(Prototype)
5. 单例模式(Singleton)

• 结构型模式

1. 适配器模式(Adapter)
2. 桥接模式(Bridge)
3. 组合模式(Composite)
4. 装饰模式(Decorator)
5. 外观模式(Facade)
6. 享元模式(Flyweight)
7. 代理模式(Proxy)

• 行为型模式

1. 职责链模式(Chain of Responsibility)
2. 命令模式(Command)
3. 解释器模式(Interpreter)
4. 迭代器模式(Iterator)
5. 中介者模式(Mediator)
6. 备忘录模式(Memento)
7. 观察者模式(Observer)
8. 状态模式(State)
9. 策略模式(Strategy)
10. 模板方法模式(Template Method)
11. 访问者模式(Visitor)

4.设计模式的优点

• 设计模式融合了众多专家的经验，并以一种标准的形式供广大开发
  人员所用，它提供了一套通用的设计词汇和一种通用的语言以方便
  开发人员之间沟通和交流，使得设计方案更加通俗易懂。对于使用
  不同编程语言的开发和设计人员可以通过设计模式来交流系统设计
  方案，每一个模式都对应一个标准的解决方案，设计模式可以降低
  开发人员理解系统的复杂度。
• 设计模式使人们可以更加简单方便地复用成功的设计和体系结构，
  将已证实的技术表述成设计模式也会使新系统开发者更加容易理解
  其设计思路。设计模式使得重用成功的设计更加容易，并避免那些
  导致不可重用的设计方案。
• 设计模式使得设计方案更加灵活，且易于修改。
• 设计模式的使用将提高软件系统的开发效率和软件质量，且在一定
  程度上节约设计成本。
• 设计模式有助于初学者更深入地理解面向对象思想，一方面可以帮
  助初学者更加方便地阅读和学习现有类库与其他系统中的源代码，
  另一方面还可以提高软件的设计水平和代码质量。