6大设计原则之单一职责原则
单一职责原则的英文名称是：Single Responsibility Principle, 简称SRP。
单一职责原则定义是：应该有且仅有一个原因引起类的变更。原话：There should never be more than one reason for a class to change。
接口，类，和方法都可以应用单一职责原则。
例：
用户需求，要修改用户密码，修改用户地址，修改用户证件号码，要怎么做呢？
方法适用单一职责原则：
方法一：
function changeUserInfo($Key, $value)
{
xxxxx;
}
方法二:
function changePassWord($oldPassWord, $newPassWord)
{
xxx；
}
function changeAddress（$address）
{
xxxx;
}
function changeCard($cardType, $cardNum)
{
xxxx;
}
类似这样的方法，如果某人写了方法一，那么对不起，不管你需要改动多少代码量，必须改回去。
对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
6大设计原则之里氏替换原则
里氏替换原则的英文名称是：Liskov Substitution Principle,简称LSP
里氏替换原则定义是：所有引用基类的地方必须能透明地使用其子类的对象。
英文定义：Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。
通俗点说：所有父类能出现的地方子类就可以出现，并且替换为子类也不会产生任何错误或异常。反之则不可以。
里氏替换原则可以让继承的“优点”发挥最大作用，同时减少“缺点”带来的麻烦。
继承的优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
提高代码的重用性：“龙生龙，凤生凤”;
提高代码的可扩展性：实现父类方法就可以“为所欲为”;
提高产品或项目的开放性。
继承的缺点：
继承是入侵性的。只要继承，就必须拥有父类的所有属性和方法;
降低代码的灵活性，子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；
增强了耦合性。当父类的常量、变量和方法修改时，必须要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果，大片的代码需要重构。
例子（待补充）
如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖，聚集，组合等关系代替继承。
子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。
6大设计原则之依赖倒置原则
依赖倒置原则英文名称是：Dependence Inversion Principle,简称DIP
依赖倒置原则：（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象; （2）抽象不应该依赖细节 （3）细节应该依赖抽象
英文定义：High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details . Details should depend upon abstractions.
什么是低层模块？什么是高层模块？每一个逻辑实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。
什么是抽象？什么是细节？抽象就是指接口或抽象类，两者都不能被实例化。细节就是实现类，实现接口或集成抽象类而产生的类就是细节，可以直接实例化。
依赖倒置原则的表现：
（1）模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
（2）接口或抽象类不依赖于实现类。
（3）实现类依赖接口或抽象类。
采用依赖倒置原则优点：可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
证明可以减少类间耦合性。
例子：（待补充）
结论：设计是否具备稳定性，只要适当“松松土”，观察我们的设计，是否还可以茁壮成长就可以得出结论。稳定性高的设计，在周围环境频繁变化时，依然可以做到“我自岿然不动”；
证明减少并行开发引起的风险,并行开发最大的风险是风险扩散
4.接口隔离原则
5.迪米特法则（最少知识原则）
要求只和朋友交流，并且我只知道你提供这么多public方法 其他不管
6.开闭原则
对于扩展规则是开的。修改源码是闭的
