[TOC]
- 用PHP实现一些常用的设计模式
设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。 项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
- 可维护
- 可扩展
- 可复用
- 灵活性好
达到强内聚，松耦合
一个类只负载一项职责，不要存在多于一个导致类变更的原因
垃圾：类A负责2个职责，功能1 发生需求变化时需要修改类A有可能会导致功能2发生故障（如下图）
修改：遵循单一职责原则。分别建立类A和类B，分别负责功能1和功能2，这样修改功能1就不会对功能2造成任何影响了
-
降低需求改改改带来的风险
-
降低类的复杂度，一个类只负责一项职责，逻辑简单粗暴
-
提高类的可读性，提高系统的可维护性
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
子类可以扩展父类功能，但是不能修改父类功能。所有引用基类的地方必须能透明地使用其子类的对象
高层模块不应该依赖低层模块，二者都应该依赖其抽象，抽象不应该依赖细节；细节应该依赖抽象。 针对接口编程,不要针对实现编程
例如
业务逻辑层相对于数据层是高层模块，因为业务逻辑层需要调用数据层去连接数据库，但是要做到可扩展高复用，
尽量不要让业务逻辑层依赖数据层，可以在数据层抽象出一个接口，让业务逻辑层依赖于这个抽象接口。
宠物类（高层）直接依赖狗类（低层），假如狗狗走丢了又重新养了一只猫，需要直接依赖猫类（新低层），
就必须修改宠物类的代码来达成。假如修改高层就会有很多不必要的风险（比如换个狗碗。。。）
列如策略模式
- 低层模块尽量都要有抽象类或接口，或者两者都有
- 变量的声明类型尽量是抽象类或接口。
- 使用继承时遵循里氏替换原则。
不依赖不需要的接口，一个类对另一个类的依赖建立在最小接口上，降低类之间的耦合度
- 凡事有度，接口的细化可以提高代码设计的灵活性，但是过小的划分会造成接口数量过多，使用设计复杂
- 为依赖接口定制服务，只暴露给调用类调用他的需要方法
一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立
最少知道原则.如果两个类不必直接通信那么这两个类就不应当发生直接的相互作用.
如果其中一个类需要调用另一个类,可以通过第3者转发这个应用
类与类之间关系越密切。耦合度越大，当一个类发生变化时，对另一个类的影响也越大
高内聚：一类尽量减少对其他对象的依赖，并且这个类的方法和属性能用私有就尽量私有化。
-
只与直接的朋友通信，不和陌生人说话
-
过分的使用该原则，将导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
开闭原则：实现热插拔，提高扩展性。
#ps 里氏代换原则：实现抽象的规范，实现子父类互相替换；
依赖倒转原则：针对接口编程，实现开闭原则的基础；
接口隔离原则：降低耦合度，接口单独设计，互相隔离；
迪米特法则，又称不知道原则：功能模块尽量独立；
合成复用原则：尽量使用聚合，组合，而不是继承；