单一职责原则

单一职责原则：不要存在多于一个导致 类变更的原因
各自类负责自己的事务

重构前

getConnection()方法用于连接数据库，
findCustomers()用于查询所有的客户信息，
createChart()用于创建图表，
displayChart()用于显示图表。

我们观察这个类，CustomerDataChart类承担了太多的职责，既包含与数据库相关的方法，又包含与图表生成和显示相关的方法。
如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息，则难以实现代码的重用

我们需要将能重用的方法，自身特色的方法拆开

重构后

image.png

DBUtil：负责连接数据库，包含数据库连接方法getConnection()；
CustomerDAO：负责操作数据库中的Customer表，包含对Customer表的增删改查等方法，如findCustomers
CustomerDataChart：负责图表的生成和显示，包含方法createChart()和displayChart()。

每个类的职责大大减少 且可以复用

里氏替换原则

里氏替换原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常

重构前

image.png

这个模型的问题在于在同个方法用到了不同的子类
那么n个子类难道需要写n个send方法？当然是不合理的

重构后

image.png

这里无论多少个子类只需写一个send方法即可
在由客户端确定具体类型

依赖倒置原则

依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象

一句话：针对接口编程

重构前

在客户数据操作类中将调用数据格式转换类的方法实现格式转换和数据库插入操作

但若数据传输的格式是变化的，那么每变化一次就要去CustomDAO修改使用的格式转换器，这是一个很大的问题

重构后

image.png

重构后
只需修改配置参数后通过抽象类获取不同的转换器

接口隔离原则

接口隔离原则：客户端不应该被强迫地依赖那些根本用不上的方法。

即使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

重构前

image.png

接口中的职责过多 实现的类都要实现一些无意义的空方法

重构后

image.png

一句话：找需要的接口实现

迪米特法则:

迪米特法则:一个对象应该对其他对象保持最少的了解

一句话：解耦

重构前

image.png

耦合太严重
修改了button 其他的源码都要变化

重构后

image.png

采用中间类来做中介 改button只需改mediator

开闭原则

开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

白话就是不要改你以前写的代码，你应该加一些代码去扩展原来的功能，来实现新的需求

重构前

image.png

重构后

image.png

增加一个抽象图表类AbstractChart，将各种具体图表类作为其子类
ChartDisplay类针对抽象图表类进行编程，由客户端来决定使用哪种具体图表

总结

在平时编程中要做到以下的规范：
解耦，可扩展，面向接口编程，多接口（接口职业化），类职业化，抽象引用具体使用