2.4 依赖倒转原则

定义：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

注意点：依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层 类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据 类型的转换等，而不要用具体类来做

这些事情。为了确保该原则的应用，一个具体类应当只 实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增 加的新方法。

在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体 类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改 配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭 原则的要求。在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入 (DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发 生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注 入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传

入具体类的对象， 设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务 方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型 的对象，由子类对象来覆

盖父类对象。

总结：

1、针对接口编程

2、在接口或抽象类中定义方法、声明变量

3、类只实现接口或抽象类中的方法，不要定义多余的方法

4、给抽象对象或接口注入依赖对象时，采用依赖注入方式

实例：

我们可以把之前的开闭原则案例修改一下，利用Spring框架进行修改，可读性更强，同时遵循了开闭原则、里氏代换

原则和依赖倒转原则，如下图：

2.5 接口隔离原则

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

1、针对接口编程

2、在接口或抽象类中定义方法、声明变量

3、类只实现接口或抽象类中的方法，不要定义多余的方法

4、给抽象对象或接口注入依赖对象时，采用依赖注入方式

讲解：接口仅仅提供客户端 需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接

口， 而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的 所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口 中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便， 并都承担某一单一角色。接口应该尽细化，同时接口中的方法

应该尽量少，每个接口中只 包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即 为不同的客户端提供宽窄不同的接口。

总结：

需要用到哪些方法，接口中就只提供哪些方法，用不到的方法，接口中不提供。

注意：

我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系 统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强 迫客户依赖于那些它们不用的方法。

实例：下图展示了一个拥有多个客户类的系统，在系统中定义了一个巨大的接口DataRead来服务所有的客户类。

原始设计方案：

基于接口隔离原则进行重构:

2.6 合成复用原则

定义：尽量使用对象组合，而不是继承来达到复用的目的。

讲解：合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些 已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能 的目的。简言之：复用时要尽量使用组

合/聚合关系（关联关系），少用继承。在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/ 聚合关系或通过继

承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低 类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使 用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于

对问题的理解，降低复杂 度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用

继 承复用。通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实 现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白 箱”复用，如果基类发生改变，那么子类的

实现也不得不发生改变；由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现 细节对于新对象不可见。

总结：

复用的方式：

①组合/聚合关系实现复用

②继承实现复用 继承复用问题：会破坏系统的封装性，会把基类实现暴露给子类。

组合/聚合复用：已有对象的功能细节，对组合而成的新对象是不可见的，封装性教好。

实例：图书管理系统中，如果数据在MySQL中，我们需要创建一个链接MySQL的工具类 MySQLUtil ,Dao只需要继承

该工具类即可操作数据库，如果把数据库换成Oracle，我们需要新建一个工具类 OracleUtil ，Dao需要修改继承对

象改为 OracleUtil ,这就违反了开闭原则。

原始设计方案：

基于合成复用原则进行重构:

我们把 OracleUtil 作为 MySQLUtil 的子类，BookDao中把 MySQLUtil 作为一个属性组合进来，每次需要变更数据

库链接的时候，只需要修改BookDao的依赖注入配置文件即可。这里符合里氏替换原则。

2.7 迪米特法则

定义：一个软件实体应当尽可能少地与其他实体发生相互作用。

讲解：如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少地影响其他 模块，扩展会相

对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之 间通信的宽度和深度。迪米特法则可降

低系统的耦合度，使类与类之间保持松散的耦合关系。

迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必 彼此直接通信，那么这

两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需 要调用另一个对象的某一个方法的话，可以通

过第三者转发这个调用。简言之，就是通过引 入一个合理的第三者来降低现有对象之间的耦合度。

作用：降低系统的耦合度

实例：我们在做增删改查的时候，如果直接用控制层调用Dao，业务处理的关系会比较乱，我们需要合理增加一个中

间对象(业务层)来解决个问题。

原始设计方案：

基于迪米特法则进行重构：

3 设计模式分类

GOF中共提到了23种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使用多种设计模式。这23种设计模式根据功能作用来划分，可以划分为3类：

(1)创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”，单例、原型、工厂方法、抽象工厂、建造者5种设计模式属于创建型模式。

(2)结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，代理、适配器、桥接、装饰、外观、享元、组合7种设计模式属于结构型模式。

(3)行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器11种设计模式属于行为型模式。