面向对象设计原则-2-优快云博客

里氏代换原则

里氏代换原则：所有引用基类的地方必须能透明地使用其子类的对象。

Liskov Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

要针对接口（或抽象层）编程，不要针对实现编程
开闭原则是面向对象设计的目标，里氏代换原则是面向对象设计的主要实现机制之一

实例：

以上一节的开闭原则的例子：

依赖倒转原则

分析
        高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。
        在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等
        在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中（比如使用反射机制）

实例：

某软件公司开发人员在开发CRM系统时发现：该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中，因此需要进行数据格式转换。在客户数据操作类CustomerDAO中将调用数据格式转换类的方法来实现格式转换，初始设计方案结构如图2-3所示：

初始设计方案结构图

在编码实现所示结构时，该软件公司开发人员发现该设计方案存在一个非常严重的问题，由于每次转换数据时数据来源不一定相同，因此需要经常更换数据转换类，例如有时候需要将TXTDataConvertor改为ExcelDataConvertor，此时，需要修改CustomerDAO的源代码，而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码，系统扩展性较差，违反了开闭原则，需要对该方案进行重构。

实例解析

接口隔离原则

接口隔离原则定义

接口隔离原则：客户端不应该依赖那些它不需要的接口。

Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use.

分析
        当一个接口太大时，需要将它分割成一些更细小的接口
        使用该接口的客户端仅需知道与之相关的方法即可
        每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干

“接口”定义(1)：一个类型所提供的所有方法特征的集合。一个接口代表一个角色，每个角色都有它特定的一个接口，“角色隔离原则”
“接口”定义(2)：狭义的特定语言的接口。接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口，每个接口中只包含一个客户端所需的方法，“定制服务”

合成复用原则

合成复用原则定义

合成复用原则：优先使用对象组合，而不是继承来达到复用的目的。

Composite Reuse Principle (CRP)：Favor composition of objects over inheritance as a reuse mechanism.

合成复用原则又称为组合/聚合复用原则(Composition/ Aggregate Reuse Principle, CARP)

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

继承复用：实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用）
组合/聚合复用：耦合度相对较低，有选择性地调用成员对象的操作；可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。（“黑箱”复用）

某软件公司开发人员在初期的CRM系统设计中，考虑到客户数量不多，系统采用Access作为数据库，与数据库操作有关的类，例如CustomerDAO类等都需要连接数据库，连接数据库的方法GetConnection()封装在DBUtil类中，由于需要重用DBUtil类的GetConnection()方法，设计人员将CustomerDAO作为DBUtil类的子类，初始设计方案结构如图2-7所示。

图-初始设计方案结构图

随着客户数量的增加，系统决定升级为Oracle数据库，因此需要增加一个新的OracleDBUtil类来连接Oracle数据库，由于在初始设计方案中CustomerDAO和DBUtil之间是继承关系，因此在更换数据库连接方式时需要修改CustomerDAO类的源代码，将CustomerDAO作为OracleDBUtil的子类，这将违背开闭原则。当然也可以直接修改DBUtil类的源代码，这同样也违背了开闭原则。

现使用合成复用原则对其进行重构。

迪米特法则

迪米特法则定义
迪米特法则又称为最少知识原则(Least Knowledge Principle, LKP)

迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

Law of Demeter (LoD): Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目
迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用
应用迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系
不要和“陌生人”说话 (Don't talk to strangers.)

只与你的直接朋友通信 (Talk only to your immediate friends.)

(1) 当前对象本身(this)

(2) 以参数形式传入到当前对象方法中的对象

(3) 当前对象的成员对象

(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友

(5) 当前对象所创建的对象

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”

在应用迪米特法则时，一个对象只能与直接朋友发生交互，不要和“陌生人”发生直接交互，这样做可以降低系统的耦合度，一个对象的改变不会给太多其他对象带来影响

迪米特法则要求在设计系统时，应该尽量减少对象之间的交互

如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用

如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用

通过引入一个合理的“第三者”来降低现有对象之间的耦合度

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