设计模式：设计原则
1.单一职责（SRP）
单一职责原则（Single Responsibility Principle）定义：
应该有且仅有一个原因引起类的变更。
使用单一职责的优点：
1. 类的复杂性降低，实现什么职责都有清晰明确的定义；
2. 可读性提高，复杂性降低;
3.可维护性提高，可读性提高;
4.变更引起的风险降低，一个接口修改只对相应的实现类有影响，对其他的接口无影响
样例1：将用户管理拆分为两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更
<?php /** *Business Object(业务对象),负责用户收集和反馈用户的属性信息 */ interface IUserBo{ function setUserId(/* String */ $userId); function getUserId(); function setPassword(/* String */ $password); function setUserName(/* String */ $userName); function getUserName(); } /** *Business Logic(业务逻辑),负责用户的行为,完成用户信息的维护和变更 */ interface IUserBiz{ function changePassword(/* String */ $userId, /* String */ $password); function deleteUser(/* IUserBo */ $userBo); function mapUser(/* IUserBo */ $userBo); function addOrg(/* IUserBo */ $userBo, /* String */$orgId); function addRole(/* IUserBo */ $userBo, /* String */$roleId); } /** *Business Logic (业务逻辑),负责处理用户的行为 */ interface IUserInfo extends IUserBo, IUserBiz{ } class UserInfo implements IUserInfo(){ }
样例2：
/** *Business Object(业务对象),负责用户收集和反馈用户的属性信息 */ interface IUserBo{ function setUserId(/* String */ $userId); function getUserId(); function setPassword(/* String */ $password); function setUserName(/* String */ $userName); function getUserName(); } /** *Business Logic(业务逻辑),负责用户的行为,完成用户信息的维护和变更 */ interface IUserBiz extends IUserBo{ function changePassword(/* String */ $userId, /* String */ $password); function deleteUser(/* IUserBo */ $userBo); function mapUser(/* IUserBo */ $userBo); function addOrg(/* IUserBo */ $userBo, /* String */$orgId); function addRole(/* IUserBo */ $userBo, /* String */$roleId); } class UserBo implements IUserBo { } class IUserBiz implements IUserBiz{ }
2. 里氏替换原则（LSP）
里氏替换原则（Liskov Substitution Principle)定义:
(1)如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
(2)所有引用基类的地方必须能透明地使用其子类的对象。（子类可以扩展父类的功能，但不能改变父类原有的功能。）
里氏替换原则包含以下4层含义：
- 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
使用继承优点：
1.代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
2. 提高代码的重用性；
3.子类可以形似父类，但又异于父类；
4.提高代码的可扩展性；
5.提高产品或项目的开放性；
继承缺点:
1.继承是侵入性的。只要继承，就必须拥有父类的所有方法和属性；
2.降低代码的灵活性。子类必须拥有父类的属性和方法;
3.增强了耦合性。当父类的变量和方法被修改时，就需要考虑子类的修改；
在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对。
遵循里氏替换原则，尽量避免子类重写父类的方法，也尽量避免重载父类的方法，可以有效降低代码出错的可能性。
3. 依赖倒置原则（DIP）
依赖倒置原则（ Dependence Inversion Principle,DIP）定义:
1. 高层不应该依赖低层模块，两者都应该依赖其抽象、
2. 抽象不应该依赖细节
3. 细节应该依赖抽象
实现规则：
1. 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
2. 变量的表面类型尽量是接口或抽象类
3. 任何类都不应该从具体类派生
4. 尽量不要复写基类的方法
5. 结合里氏替换原则使用
样例代码：
<?php interface IDriver { function drive(ICar $car); } interface ICar { function run(); } class Benz implements ICar { function run(){ echo "奔驰开动了"; } } class BMW implements ICar { function run(){ echo "宝马开动了"; } } class Driver implements IDriver { function drive(ICar $car){ $car->run(); } } $car_1 = new BMW(); (new Driver())->drive($car_1);
4. 接口隔离原则
接口隔离原则定义：
1. 客户端不应该依赖它不需要的接口。
2. 类间的依赖关系应该监理在最小接口上
实现规范：
1. 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性 是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
2. 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
3. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
5. 迪米特法则/最少知识原则
迪米特法则（ Law of Demeter， LoD)/最少知识原则（ Least Knowledge Principle， LKP）定义：
一个对象应该对其他对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道的最少。
6. 开闭原则
开闭原则 定义：
一个软件实体如类、模块、和函数应该对扩展开发，对修改关闭。
设计模式
1. 创建设计模式（Creational Patterns）
用于创建对象时的设计模式。更具体一点，初始化对象流程的设计模式。当程序日益复杂时，需要更加灵活地创建对象，同时减少创建时的依赖。而创建设计模式就是解决此问题的一类设计模式。
