设计模式六大原则简介

这篇文章大概讲一下设计模式的六大原则，讲解没有原则的方式是：简单定义->问题由来->解决方案或者需要注意的地方

1.单一职责原则

定义：不要存在多余一个导致类变更的原因（一个类只负责一项职责）。

问题由来：类T负责两个不同的职责：职责P1和职责P2。当由于职责P1的需求发生改变而需要修改类T的时候，可能导致运行正常的职责P2的功能发生故障。

注意：其实很多事，我们都会注意功能模块化设计的，都会注意尽量实现接口编程，都会注意尽量实现低耦合高内聚，但是所有的这一切都不如需求来的快，所以我们要在职责扩散到我们无法控制的程度之前立刻对代码进行重构。

2.里氏替换原则（LSP）

定义：子类型能够完全的替换父类型而程序在功能上不受影响。

问题由来：类A能完成P1功能，现在需要P2功能，那么类B继承类A并开展了P2功能，即类B有P1和P2功能，这个时候有可能在扩展的时候破坏了P1的功能。

注意：子类不要覆盖父类已有非抽象方法，这样会破坏继承体系，如果非要修改的话，让子类和父类都继承更底层的基类

3.依赖倒置原则

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

问题由来：类A直接依赖类B，加入要将类A改为依赖类C，则必须修改类A的代码完成。类A一般是高层模块如客户端，类B和类C是低层模块，负责基本的原子操作。（依赖的意思就是在类A中声明了一个类B的引用，无论是属性里面还是形参里面）

解决办法：将类B和类C抽象为一个借口I，而类A改为依赖借口I，这样类A就通过接口I间接与类B和类C发生联系，降低类A的修改几率。

注意：

a.低层模块尽量要有抽象类或接口或两者都有

b.变量的声明类型尽量是抽象类或接口

c.使用继承是记得要遵循里氏替换原则

4.接口隔离原则

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

问题由来：类A通过接口I依赖类B，而接口I对类A和类B都不是最小接口，而类B必须去实现它们不需要的方法

解决办法：将这个接口分解为更小的多个接口。至于接口的划分需要仔细思考的。

5.迪米特原则

定义：一个对象应对其他对象保存最小的了解。

问题来由：类与类直接的关系越密切，耦合度越大，当一个类发生改变的时候，对另一个类的影响越大。

其实就是低耦合高内聚。

6.开发-封闭原则

定义：一个软件实体如类、模块和函数应该对扩展开发，对修改关闭。

问题由来：在软件生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，而且需要原有代码经过重新测试。

解决办法：当软件需求方式变化的时候，我们进行扩展软件的行为来实现变化，而不是对原有的代码进行修改来实现变化。