设计模式之————面向对象7大设计原则及实例

面向对象7大设计原则及实例

开闭原则(Open-Closed Principle,OCP)

开闭原则是这七大设计原则中最常见、最基本的

开闭原则定义：软件实体对扩展是开放的，但对修改是关闭的。意思就是说在不修改软件实体的基础上去扩展其他功能。

开闭原则实例：

比如实现一个绘制图线的功能

设计方案如下图所示

用户类中直接调用画直线类，但是如果有一个新需求，要求我们画斜线或者曲线的话，这时就需要修改画直线类中的代码（使用switch，else if），这样就违背了开闭原则，于是我需要在不修改实体的基础上去扩展画斜线和曲线功能

重构后的代码设计方案如下图所示

单一职责原则(Simple Responsibility Principle,SRP)

如果一个类具有多个职责，应该把这多个职责分离出去，再分别创建一些类去一一完成这些职责，换句话说就是一个类的职责要单一，不能将太多的职责放在一个类中
单一职责核心：高内聚、低耦合
如下图是一个类画线的实现：
但是功能太过集中，严重违背了单一职责原则，重构后如下图所示

里氏替换原则(Liskov Substitution Principle,LSP)

是继承复用的基石，说白了就是继承与派生的规则

里氏替换原则核心：在软件系统中，一个可以接受父类对象的地方必然可以接受子类对象

里氏替换原则实例：某系统需要实现画直线功能，现在有DrawLineA和DrawLineB两种画图方式，在操作类中提供了这两种画图方法选择画直线

现在我需要改变或添加一种画直线方式来画直线，比如原先使用DrawLineA方式进行画直线现在更换为DrawLineB方式来画直线，如果直接修改操作类的代码就违背了开闭原则。现在使用里氏替换原则重构代码，既可以方便了系统扩展，又遵循了开闭原则

所以说里氏替换原则是实现开闭原则的重要方法之一

依赖倒置原则（Dependence Inversion Principle,DIP）

依赖倒置也叫依赖注入、依赖倒转

要针对抽象层编程，不要针对具体类编程

依赖倒置原则核心：要依赖于抽象，不要依赖于具体的实现。

分开来说：（注：抽象:接口或抽象类;细节:具体实现;如果把模块层次关系比作基础关系的话:高层模块和底层模块对应于父类和子类）

一、高层模块不应该依赖底层模块，这两者应该依赖与其抽象

二、抽想不应该依赖细节

三、细节应依赖抽象

依赖倒置实例：

比如某系统可以从本地获取和服务器获取数据，后将数据可以为转化配置成XML文件和XLS文件

假设我们增加了数据源或者有新的转化格式，需要修改操作类里面的源代码，这样就违背了开闭原则

现在使用依赖倒置原则对其进行重构

重构方案图如下图所示

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

使用多个专门接口来取代一个统一的接口，

一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口中。

接口隔离原则核心：不应该强迫客户端程序依赖他们 不需要的使用方法

接口隔离原则实例：

比如一个系统中有一个大的接口，这个接口包含了GameobjectA、GameobjecB、GameobjectC三个对象的接口

但是这三个对象中有些接口未必需要实现，现在使用接口隔离原则将接口隔离，这样又满足单一职责原则

重新构造的方案如下图所示

迪米特原则(Law of Demeter,LOD)

又叫做最少知识原则，一个软件实体对其他实体的引用越少越好，或者说如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用，而是通过一个第三者发生间接性的交互。

迪米特原则核心：高内聚，低耦合

地米特原理实例：

比如某一系统有多个系统和多个数据源，他们之间的联系图如下：

这样比较杂乱，耦合性较高，使用迪米特原则后的构造方案如下图所示：

迪米特原则缺点：

一、降低模块间的通信效率

二、在系统的各个角落散落大量的小方法

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

在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合或通过继承。

继承复用：实现简单，便于扩展。但是破坏系统的封装性。

组合复用：耦合性相对较低，选择性的调用成员对象的操作。可以再运行时动态运行。

合成复用核心：尽量使用对象组合而不是继承达到复用的目的