开闭原则(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文件
假设我们增加了数据源或者有新的转化格式,需要修改操作类里面的源代码,这样就违背了开闭原则
现在使用依赖倒置原则对其进行重构
重构方案图如下图所示
实例解析OOP程序设计七大设计原则(二)
接口隔离原则(Interface Segregation Principle,ISP)
使用多个专门接口来取代一个统一的接口,
一个接口不需要提供太多的行为,一个接口应该只提供一种对外的功能,不应该把所有的操作都封装到一个接口中。
接口隔离原则核心:不应该强迫客户端程序依赖他们 不需要的使用方法
接口隔离原则实例:
比如一个系统中有一个大的接口,这个接口包含了GameobjectA、GameobjecB、GameobjectC三个对象的接口
但是这三个对象中有些接口未必需要实现,现在使用接口隔离原则将接口隔离,这样又满足单一职责原则
重新构造的方案如下图所示
迪米特原则(Law of Demeter,LOD)
又叫做最少知识原则,一个软件实体对其他实体的引用越少越好,或者说如果两个类不必直接通信,那么这两个类就不应当发生直接的相互作用,而是通过一个第三者发生间接性的交互。
迪米特原则核心:高内聚,低耦合
低迷特原理实例:
比如某一系统有多个系统和多个数据源,他们之间的联系图如下:
这样比较杂乱,耦合性较高,使用迪米特原则后的构造方案如下图所示:
迪米特原则缺点:
一、降低模块间的通信效率
二、在系统的各个角落散落大量的小方法
合成复用原则(Composite Reuse Principle,CRP)
在面向对象设计中,可以通过两种基本方法在不同的环境中复用已有的设计和实现,即通过组合或通过继承。
继承复用:实现简单,便于扩展。但是破坏系统的封装性。
组合复用:耦合性相对较低,选择性的调用成员对象的操作。可以再运行时动态运。.
合成复用核心:尽量使用对象组合而不是继承达到复用的目的