开闭原则(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)
在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合或通过继承。
继承复用：实现简单，便于扩展。但是破坏系统的封装性。
组合复用：耦合性相对较低，选择性的调用成员对象的操作。可以再运行时动态运。.
合成复用核心：尽量使用对象组合而不是继承达到复用的目的
微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站。（关注公众号后回复”Java“即可领取 Java基础、进阶、项目和架构师等免费学习资料，更有数据库、分布式、微服务等热门技术学习视频，内容丰富，兼顾原理和实践，另外也将赠送作者原创的Java学习指南、Java程序员面试指南等干货资源）
