|
|
|
|
@ -0,0 +1,209 @@
|
|
|
|
|
## 面向对象设计原则概述
|
|
|
|
|
|
|
|
|
|
- **可维护性(Maintainability)：指软件能够被理解、改正、适应及扩展的难易程度**
|
|
|
|
|
- **可复用性(Reusability)：指软件能够被重复使用的难易程度**
|
|
|
|
|
- 面向对象设计的目标之一在于**支持可维护性复用**，一方面需要实现设计方案或者源代码的复用，另一方面要确保系统能够易于扩展和修改，具有良好的可维护性
|
|
|
|
|
- 面向对象设计原则为**支持可维护性复用而诞生**
|
|
|
|
|
- **指导性原则，非强制性原则**
|
|
|
|
|
- 每一个设计模式都符合一个或多个面向对象设计原则，面向对象设计原则是**用于评价一个设计模式的使用效果的重要指标之一**
|
|
|
|
|
|
|
|
|
|
| **设计原则名称** | **定** **义** | **使用频率** |
|
|
|
|
|
| ------------------------------------------------------ | ------------------------------------------------------------ | ------------ |
|
|
|
|
|
| **单一职责原则(Single Responsibility Principle, SRP)** | **一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中** | ★★★★☆ |
|
|
|
|
|
| **开闭原则(Open-Closed Principle, OCP)** | **软件实体应当对扩展开放，对修改关闭** | ★★★★★ |
|
|
|
|
|
| **里氏代换原则(LiskovSubstitution Principle, LSP)** | **所有引用基类的地方必须能透明地使用其子类的对象** | ★★★★★ |
|
|
|
|
|
| **依赖倒转原则(Dependence Inversion Principle, DIP)** | **高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象** | ★★★★★ |
|
|
|
|
|
| **接口隔离原则(Interface Segregation Principle, ISP)** | **客户端不应该依赖那些它不需要的接口** | ★★☆☆☆ |
|
|
|
|
|
| **合成复用原则(Composite Reuse Principle, CRP)** | **优先使用对象组合，而不是继承来达到复用的目的** | ★★★★☆ |
|
|
|
|
|
| **迪米特法则(Law of Demeter,LoD)** | **每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位** | ★★★☆☆ |
|
|
|
|
|
|
|
|
|
|
## 单一职责原则
|
|
|
|
|
|
|
|
|
|
> 单一职责原则定义
|
|
|
|
|
|
|
|
|
|
**单一职责原则**：一个对象应该**只包含单一的职责**，并且该职责被完整地封装在一个类中。
|
|
|
|
|
**Single Responsibility Principle (SRP)**: Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
|
|
|
|
|
|
|
|
|
|
- 单一职责原则是最简单的面向对象设计原则，**用于控制类的粒度大小**
|
|
|
|
|
- 就一个类而言，应该**仅有一个引起它变化的原因**
|
|
|
|
|
- There should never be more than **one reason for a class to change**.
|
|
|
|
|
|
|
|
|
|
> 单一职责原则分析
|
|
|
|
|
|
|
|
|
|
- 一个类（大到模块，小到方法）**承担的职责越多**，它**被复用的可能性就越小**
|
|
|
|
|
- **当一个职责变化时**，可能**会影响其他职责的运作**
|
|
|
|
|
- 将这些职责进行分离，**将不同的职责封装在不同的类中**
|
|
|
|
|
- 将不同的变化原因封装在不同的类中
|
|
|
|
|
- 单一职责原则**是实现高内聚、低耦合的指导方针**
|
|
|
|
|
|
|
|
|
|
> 单一职责原则实例
|
|
|
|
|
|
|
|
|
|
- 实例说明
|
|
|
|
|
|
|
|
|
|
某软件公司开发人员针对CRM（Customer Relationship Management，客户关系管理）系统中的客户信息图表统计模块提出了如图所示的初始设计方案。
|
|
|
|
|
|
|
|
|
|
getConnection()方法用于连接数据库，findCustomers()用于查询所有的客户信息，createChart()用于创建图表，displayChart()用于显示图表。
|
|
|
|
|
现使用单一职责原则对其进行重构。
|
|
|
|
|
|
|
|
|
|
- 实例解析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 开闭原则
|
|
|
|
|
|
|
|
|
|
> 开闭原则定义
|
|
|
|
|
|
|
|
|
|
**开闭原则**：软件实体应当**对扩展开放，对修改关闭**。
|
|
|
|
|
**Open-Closed Principle (OCP)**: Software entities should be **open for extension**, but **closed for modification.**
|
|
|
|
|
|
|
|
|
|
- 开闭原则是**面向对象的可复用设计的第一块基石**，是最重要的面向对象设计原则
|
|
|
|
|
- 开闭原则由**Bertrand Meyer**于1988年提出
|
|
|
|
|
- 在开闭原则的定义中，软件实体可以是**一个软件模块**、**一个由多个类组成的局部结构**或**一个独立的类**
|
|
|
|
|
- 开闭原则是指**软件实体应尽量在不修改原有代码的情况下进行扩展**
|
|
|
|
|
|
|
|
|
|
> 开闭原则分析
|
|
|
|
|
|
|
|
|
|
- **抽象化**是开闭原则的关键
|
|
|
|
|
- 相对稳定的**抽象层** + 灵活的**具体层**
|
|
|
|
|
- **对可变性封装原则(Principle of Encapsulation of Variation, EVP)**：找到系统的可变因素并将其封装起来
|
|
|
|
|
|
|
|
|
|
## 里氏代换原则
|
|
|
|
|
|
|
|
|
|
> 里氏替换原则定义
|
|
|
|
|
|
|
|
|
|
**里氏代换原则**：所有引用**基类**的地方必须能透明地使用其**子类**的对象。如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。
|
|
|
|
|
**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.If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
|
|
|
|
|
|
|
|
|
|
> 里氏替换原则分析
|
|
|
|
|
|
|
|
|
|
- 里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授Barbara Liskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 在软件中**将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常**，反过来则不成立。如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象
|
|
|
|
|
- 在程序中**尽量使用基类类型来对对象进行定义**，而在运行时再确定其子类类型
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 依赖倒转原则
|
|
|
|
|
|
|
|
|
|
> 依赖倒转原则定义
|
|
|
|
|
|
|
|
|
|
**依赖倒转原则**：高层模块不应该依赖低层模块，它们都应该依赖抽象。**抽象不应该依赖于细节，细节应该依赖于抽象。**
|
|
|
|
|
**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.**
|
|
|
|
|
|
|
|
|
|
> 依赖倒转原则分析
|
|
|
|
|
|
|
|
|
|
- 依赖倒转原则是**Robert C. Martin**在1996年为“C++ Reporter”所写的专栏Engineering Notebook的第三篇，后来加入到他在2002年出版的经典著作《Agile Software Development, Principles, Patterns, and Practices》一书中
|
|
|
|
|
- 在程序代码中传递参数时或在关联关系中，**尽量引用层次高的抽象层类**，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等
|
|
|
|
|
- **在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中**
|
|
|
|
|
- 针对抽象层编程，将具体类的对象通过**依赖注入(Dependency Injection, DI)**的方式注入到其他对象
|
|
|
|
|
- 构造注入
|
|
|
|
|
- 设值注入（Setter注入）
|
|
|
|
|
- 接口注入
|
|
|
|
|
|
|
|
|
|
>OCP/LSP/DIP综合实例
|
|
|
|
|
|
|
|
|
|
- 实例 说明
|
|
|
|
|
|
|
|
|
|
某软件公司开发人员在开发CRM系统时发现：该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中，因此需要进行数据格式转换。在客户数据操作类CustomerDAO中将调用数据格式转换类的方法来实现格式转换，初始设计方案结构如图所示：
|
|
|
|
|
|
|
|
|
|
该软件公司开发人员发现该设计方案存在一个非常严重的问题，由于每次转换数据时数据来源不一定相同，因此需要经常更换数据转换类，例如有时候需要将TXTDataConvertor改为ExcelDataConvertor，此时需要修改CustomerDAO的源代码，而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码，系统扩展性较差，违反了开闭原则，现需要对该方案进行重构。
|
|
|
|
|
|
|
|
|
|
- 实例解析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 接口隔离原则
|
|
|
|
|
|
|
|
|
|
> 接口隔离原则定义
|
|
|
|
|
|
|
|
|
|
**接口隔离原则**：客户端**不应该依赖那些它不需要的接口。** **Interface Segregation Principle (ISP)**: Clients **should not be forced to depend upon interfaces that they do not use.**
|
|
|
|
|
|
|
|
|
|
> 接口隔离原则分析
|
|
|
|
|
|
|
|
|
|
- 当一个接口太大时，需要将它**分割成一些更细小的接口**
|
|
|
|
|
- 使用该接口的客户端**仅需知道与之相关的方法**即可
|
|
|
|
|
- 每一个接口应该**承担一种相对独立的角色**，不干不该干的事，该干的事都要干
|
|
|
|
|
- **“接口”定义(1)**：**一个类型所提供的所有方法特征的集合。**一个接口代表一个角色，每个角色都有它特定的一个接口，“**角色隔离原则**”
|
|
|
|
|
- **“接口”定义(2)**：**狭义的特定语言的接口。**接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口，每个接口中只包含一个客户端所需的方法，“**定制服务**”
|
|
|
|
|
|
|
|
|
|
> 接口隔离原则实例
|
|
|
|
|
|
|
|
|
|
- 实例说明
|
|
|
|
|
|
|
|
|
|
某软件公司开发人员针对CRM系统的客户数据显示模块设计了如图所示CustomerDataDisplay接口，其中方法readData()用于从文件中读取数据，方法transformToXML()用于将数据转换成XML格式，方法createChart()用于创建图表，方法displayChart()用于显示图表，方法createReport()用于创建文字报表，方法displayReport()用于显示文字报表。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在实际使用过程中开发人员发现该接口很不灵活，例如：如果一个具体的数据显示类无须进行数据转换（源文件本身就是XML格式），但由于实现了该接口，不得不实现其中声明的transformToXML()方法（至少需要提供一个空实现）；如果需要创建和显示图表，除了需要实现与图表相关的方法外，还需要实现创建和显示文字报表的方法，否则程序在编译时将报错。
|
|
|
|
|
现使用接口隔离原则对其进行重构。
|
|
|
|
|
|
|
|
|
|
- 实例解析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 合成复用原则
|
|
|
|
|
|
|
|
|
|
> 合成复用原则定义
|
|
|
|
|
|
|
|
|
|
**合成复用原则**：优先**使用对象组合，而不是继承**来达到**复用**的目的。
|
|
|
|
|
|
|
|
|
|
**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类的源代码，这同样也违背了开闭原则。
|
|
|
|
|
|
|
|
|
|
- 实例解析
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 迪米特法则
|
|
|
|
|
|
|
|
|
|
> 迪米特法则定义
|
|
|
|
|
|
|
|
|
|
**迪米特法则**：每一个软件单位对其他的单位都只有**最少的知识**，而且局限于那些与本单位密切相关的软件单位。
|
|
|
|
|
**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”的研究项目
|
|
|
|
|
- 迪米特法则要求**一个软件实体应当尽可能少地与其他实体发生相互作用**
|
|
|
|
|
- 应用迪米特法则**可降低系统的耦合度**，使类与类之间保持松散的耦合关系
|
|
|
|
|
- 迪米特法则要求在设计系统时，应该**尽量减少对象之间的交互**
|
|
|
|
|
- 如果两个对象之间不必彼此直接通信，那么这两个对象就**不应该发生任何直接的相互作用**
|
|
|
|
|
- 如果其中一个对象需要调用另一个对象的方法，可以通过**“第三者”转发**这个调用
|
|
|
|
|
- 通过**引入一个合理的“第三者”来降低现有对象之间的耦合度**
|
|
|
|
|
|
|
|
|
|
> 迪米特法则实例
|
|
|
|
|
|
|
|
|
|
- 实例说明
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
某软件公司所开发CRM系统包含很多业务操作窗口，在这些窗口中，某些界面控件之间存在复杂的交互关系，一个控件事件的触发将导致多个其他界面控件产生响应。例如，当一个按钮(Button)被单击时，对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变，在初始设计方案中，界面控件之间的交互关系可以简化为如图所示的结构。
|
|
|
|
|
|
|
|
|
|
由于界面控件之间的交互关系复杂，导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码，系统扩展性较差，也不便于增加和删除控件。
|
|
|
|
|
现使用迪米特法则对其进行重构。
|
|
|
|
|
|
|
|
|
|
- 实例解析
|
|
|
|
|
|
|
|
|
|
|
吴尤
4 years ago
