一个类被改变的缘故原由不能超过一个，
也便是说，一个类只有一个职责，
如果职责过多，代码就会臃肿，可读性更差，也更难以掩护。
为什么要遵守单一职责原则
1、提高类的可掩护性和可读写性
一个类的职责少了，繁芜度降落了，代码就少了，可读性也就好了，可掩护性自然就高了
2、提高系统的可掩护性
系统是由类组成的，每个类的可掩护性高，相对来讲全体系统的可掩护性就高。当然，条件是系统的架构没有问题。
3、降落变更的风险
一个类的职责越多，变更的可能性就更大，变更带来的风险也就越大
如何遵守单一职责原则
合理的职责分解相同的职责放到一起，不同的职责分解到不同的接口和实现中去
单一职责原则最佳实践
在实际事情中，有一个常常会用到的设计模式，DAO模式，又叫数据访问工具，里面定义了数据库中表的增、删、改、查操作.按照单一职责原则，为什么不把增、删、改、查分别定义成四种接口？
这是由于数据库的表操作，基本上便是这四种类型，不可能变革，以是没有必要分开定义。
反而常常变革的是数据库的表构造，表构造一变，这四种操作都要随着变。
以是常日我们会针对一张表实现一个DAO，一张表就代表一种类型的职责。
接口隔离原则接口隔离原则（Interface Segregation Principle，ISP）
1.客户端不应该依赖它不须要的接口
2.类间的依赖关系该当建立在最小的接口上
普通来讲：利用多个专门的接口比利用单一的总接口要好。
接口如果能够保持粒度够小，就能担保它足够稳定。
换而言之，从一个客户类的角度来讲：一个类对其余一个类的依赖性应该是建立在最小接口上的。过于臃肿的接口是对接口的污染。
不应该强制客户依赖于它们不用的方法。
接口隔离原则与单一职责原则比拟
接口隔离原则和单一职责原则非常类似
单一职责原则哀求接口的职责是单一的，
而接口隔离原则哀求接口只管即便细化。
它们有异曲同工之妙，都是要让我们的接口功能只管即便单一，只管即便小。
但是，单一职责原则的着重点是在“职责”，而接口隔离原则只纯挚地哀求接口最小化。
那么，如果已经知足单一职责原则的接口，在当前的需求下还可以连续细化，那么还须要细化吗？答案是不要再细化了。
在实践中，接口设计的粒度越小，系统就越灵巧，这是事实。
但是灵巧的同时也带来了系统的繁芜化，导致开拓难度增加。
以是接口并不是越小越好，必须要有一个度。
当单一职责原则和接口隔离原则存在抵牾时，以知足单一职责原则为底线。
开放-封闭原则开放-封闭原则（Open-Close Principle，OCP）
对付扩展是开放的
这意味着模块的行为是可以扩展的。
当运用程序的需求改变时，我们可以对其模块进行扩展，使其具有知足那些需求变更的新行为。
换句话说，我们可以改变模块的功能。
对付修恰是封闭的
对模块行为进行扩展时，不应该影响或大规模地影响已有的程序模块。
换句话说，哀求开拓职员在不修正系统现有的代码（源码或二进制代码）的条件下，实现对系统的扩展。
比如生活中的电脑，知足开放封闭原则。向电脑USB接口插入鼠标，就可以利用鼠标功能，这是开放的（扩展了鼠标功能）。我们不须要对电脑内部部件重新编排，这是封闭的（扩展了鼠标功能，但我们不须要修正电脑配置）。
但这也是相对的，对付一台电脑不可能完备开放，有些设备和功能必须保持稳定才能减少掩护上的困难。要实现一项新的功能，你就必须升级硬件，或者换一台更高性能的电脑。
里氏更换原则里氏更换原则（Liskov Substitution Principle，LSP）
1.子类必须完备实现父类的方法
在类中调用其它类时务必要利用父类或接口，如果不能利用父类或接口，则解释类的设计以及违背了LSP原则
2.子类可以拥有自己的“个性”
子类可以拥有自己的方法和属性，也可以重写（Override）或重载（Overload）父类的方法。从而拥有自己的“个性”。
但这里提起是为了再次解释一个问题——里氏更换原则可以正着用，但不能反过来利用，即子类涌现的地方，父类未必可以胜任。
依赖导致原则依赖导致原则（Dependence Inversion Principle，DIP）
高层模块不应该依赖低层模块，两者都该当依赖其抽象；
抽象不应该依赖细节；
细节该当依赖抽象。
以上3点，普通的讲：
模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
接口或抽象类不依赖于实现类；
实现类依赖接口或抽象类。
简言之便是“面向接口编程”
php7进阶到架构师干系阅读https://www.kancloud.cn/gofor/gofor
末了，欢迎大家留言补充，谈论~~~
