面向对象设计原则详解

面向对象设计原则概述

• 可维护性

  是指软件能够被理解、改正、适应和扩展的难易程度

• 可复用性

  是指软件能够被重复使用的难易程度

• 目标

  面向对象设计的目标之一在于支持可维护性复用。一方面需要实现设计方案或者源代码的复用，另一方面要确保系统能够易于扩展和修改，即具有良好的可维护性。

• 意义

  1. 面向对象设计原则为支持可维护性复用而诞生
  2. 指导性原则，非强制性原则
  3. 每个设计模式都符合一个或多个面向对象设计原则，面向对象设计原则是用于评价一个设计模式的使用效果的重要指标之一

常用的面向对象设计原则

单一职责原则（Single Responsibility Principe）SRP ★★★★☆

• 定义

  一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

  Every object should have a single responsibility，an that responsibility should be entirely encapsulated by the class.

• 是最简单的面向对象设计原则，用于控制类的粒度大小

• 就一个类而言，应该仅有一个因其他变化的原因

• 原则分析

  • 一个类（大到模块，小到方法）承担的职责越多，他被复用的可能性越小
  • 当一个职责变化时，可能会影响其他职责的运作
  • 将这些职责进行分离，将不同职责封装在不同类中
  • 将不同变化的原因封装在不同的类中
  • 单一职责原则是实现高内聚、低耦合的指导方针

• 实例说明

  某软件公司开发人员针对CRM（Customer Relationship Management，客户关系管理）系统中的客户信息图表统计模块提出了如图所示的初始设计方案。在图中，getConnection()方法用于连接数据库，findCustomers()用于查询所有的客户信息，createChart()用于创建图表，displayChart()用于显示图表。
  现使用单一职责原则对其进行重构。

  

  改进（每个类都承担相应的责任）

  

开闭原则（Open-Closed Principle）OCP ★★★★★

• 定义

  软件实体应当对扩展开放，对修改关闭。

  Software entities should be open for extension，but close for modification.

• 开闭原则是面向对象的可复用设计的一块基石，是重要的面向对象设计原则。

• 原则分析

  • 在开闭原则的定义中，软件实体可以是一个软件模块、一个由多个类组成的局部结构或一个独立的类。

  • 开闭原则是指软件实体应该尽量在不修改原有代码的情况下进行扩展。

  • 抽象化是开闭原则的关键

  • 相对稳定的抽象层+灵活的具体层

  • 对可变性封装原则(Principle of Encapsulation of Variation, EVP)：找到系统的可变因素并将其封装起来

里氏代换原则 Liskov Substitution Principle (LSP)★★★★★

• 定义

  所有引用父类的地方必须能透明地使用其子类地对象

  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.

• 原则分析

  • 在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象

  • 在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型

    

依赖倒转原则 Dependency Inversion Principle (DIP)★★★★★

• 定义

  高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖细节，细节应该依赖于抽象。

  Dependency Inversion Principle (DIP): High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.

• 针对接口编程，不应针对实现编程 Program to an interface,not an implementation.

• 原则分析

  • 在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等
  • 在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中
  • 针对于抽象层编程，将具体的类地对象通过依赖注入（Dependency Injection）地方式注入到其他对象。
    • 构造注入
    • 设值注入
    • 接口注入

• 实例分析

  某软件公司开发人员在开发CRM系统时发现：该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中，因此需要进行数据格式转换。在客户数据操作类CustomerDAO中将调用数据格式转换类的方法来实现格式转换，初始设计方案结构如图所示。
  在编码实现如图所示结构时，该软件公司开发人员发现该设计方案存在一个非常严重的问题，由于每次转换数据时数据来源不一定相同，因此需要经常更换数据转换类，例如有时候需要将TXTDataConvertor改为ExcelDataConvertor，此时需要修改CustomerDAO的源代码，而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码，系统扩展性较差，违反了开闭原则，现需要对该方案进行重构。

  使用依赖倒转原则进行改进

  

  在这里我们新增加了一个数据转换类作为父类，不同的数据转换实体类可以继承该类，同时实现该类地抽象方法readFile()，在客户端DAO层针对数据转换父类进行编程，即针对抽象编程。将具体地类通过配置文件的方式进行注入。

接口隔离原则 Interface Segregation Principle (ISP)★★☆☆☆

• 定义

  客户端不应该依赖于那些它不需要的接口。

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

• 原则分析

  • 当一个接口太大时，就必须要将他分割成一些更细小的接口
  • 使用该接口的客户端仅需知道与之相关的方法即可
  • 每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干
  • “接口”
    • 广义：一个类型所提供的所有方法特征的集合。一个接口代表一个角色，每个角色都有它特定的一个接口 “角色隔离原则”
    • 狭义：接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口，每个接口中只包含一个客户端所需的方法 ->“定制服务”

• 实例分析

  某软件公司开发人员针对CRM系统的客户数据显示模块设计了如图所示CustomerDataDisplay接口，其中方法readData()用于从文件中读取数据，方法transformToXML()用于将数据转换成XML格式，方法createChart()用于创建图表，方法displayChart()用于显示图表，方法createReport()用于创建文字报表，方法displayReport()用于显示文字报表。在实际使用过程中开发人员发现该接口很不灵活，例如：如果一个具体的数据显示类无须进行数据转换（源文件本身就是XML格式），但由于实现了该接口，不得不实现其中声明的transformToXML()方法（至少需要提供一个空实现）；如果需要创建和显示图表，除了需要实现与图表相关的方法外，还需要实现创建和显示文字报表的方法，否则程序在编译时将报错。现使用接口隔离原则对其进行重构。

  

  使用接口隔离原则进行改进

  

  从上面的改进上我们注意到两点：第一点针对一些XML和非XML文件两类我们创建了两个类别的接口，解决了XML不需要数据格式转换却仍需要实现方法（空实现），第二点针对不同的显示需求，将接口又分为两个类别分别是显示报告和显示图片，即共有4类接口，很好的满足了接口隔离原则。

合成复用原则 Composite Reuse Principle (CRP)★★★★☆

• 定义

  优先使用对象组合，而不是继承来达到复用的目的。又称为组合/聚合服用原则。

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

• 原则分析

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

• 继承复用和组合复用

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

• 实例分析

  某软件公司开发人员在初期的CRM系统设计中，考虑到客户数量不多，系统采用Access作为数据库，与数据库操作有关的类，例如CustomerDAO类等都需要连接数据库，连接数据库的方法getConnection()封装在DBUtil类中，由于需要重用DBUtil类的getConnection()方法，设计人员将CustomerDAO作为DBUtil类的子类，初始设计方案结构如图所示。随着客户数量的增加，系统决定升级为Oracle数据库，因此需要增加一个新的OracleDBUtil类来连接Oracle数据库，由于在初始设计方案中CustomerDAO和DBUtil之间是继承关系，因此在更换数据库连接方式时需要修改CustomerDAO类的源代码，将CustomerDAO作为OracleDBUtil的子类，这将违背开闭原则。当然也可以直接修改DBUtil类的源代码，这同样也违背了开闭原则。现使用合成复用原则对其进行重构。

  

  使用组合复用改进

  

  从上面的改进上看，我们摒弃了客户端DAO继承的方式，将DBUtil作为了其子类即实现组合复用，同时将其他的数据库连接工具类作为DBUtil的子类，在客户端DAO中针对父类编程，具体采用什么数据库连接方式可在配置文件中修改，即实现了依赖倒转原则。

迪米特法则 Law of Demeter (LoD)★★★☆☆

• 定义

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

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

• 该原则又被称为最少知识原则

• 法则分析

  • 迪米特法则要求在设计系统时，应该尽量减少对象之间的交互
  • 如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用
  • 如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用
  • 通过引入一个合理的“第三者”来降低现有对象之间的耦合度

• 实例分析

  某软件公司所开发CRM系统包含很多业务操作窗口，在这些窗口中，某些界面控件之间存在复杂的交互关系，一个控件事件的触发将导致多个其他界面控件产生响应。例如，当一个按钮(Button)被单击时，对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变，在初始设计方案中，界面控件之间的交互关系可以简化为如图所示的结构。在图中，由于界面控件之间的交互关系复杂，导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码，系统扩展性较差，也不便于增加和删除控件。现使用迪米特法则对其进行重构。

  

  

  使用迪米特法则（引入第三者）改进

  

  从改进结果来看，我们引入了第三媒介，传达我们的改变，采用星型结构，降低对象之间的耦合度。

以上部分相关内容出自清华大学出版社《Java设计模式》刘伟编著