php常用的设计模式

简单整理了下，PHP常用的设计模式，简单解释了该设计模式的目的。
创建型：

抽象工厂模式：
在不指定具体类的情况下创建一系列相关或依赖对象。 通常创建的类都实现相同的接口。 抽象工厂的客户并不关心这些对象是如何创建的，它只是知道它们是如何一起运行的。

建造者模式：
建造者是创建一个复杂对象的一部分接口。

有时候，如果建造者对他所创建的东西拥有较好的知识储备，这个接口就可能成为一个有默认方法的抽象类（又称为适配器）。

如果对象有复杂的继承树，那么对于建造者来说，有一个复杂继承树也是符合逻辑的。

工厂方法模式：
对比简单工厂模式的优点是，您可以将其子类用不同的方法来创建一个对象。

举一个简单的例子，这个抽象类可能只是一个接口。

这种模式是「真正」的设计模式， 因为他实现了S.O.L.I.D原则中「D」的 「依赖倒置」。

这意味着工厂方法模式取决于抽象类，而不是具体的类。 这是与简单工厂模式和静态工厂模式相比的优势

多例模式：
多例模式是指存在一个类有多个相同实例，而且该实例都是该类本身。这个类叫做多例类。 多例模式的特点是：

多例类可以有多个实例。
多例类必须自己创建、管理自己的实例，并向外界提供自己的实例。
多例模式实际上就是单例模式的推广。

对象池模式：
对象池模式是一种提前准备了一组已经初始化了的对象『池』而不是按需创建或者销毁的创建型设计模式。对象池的客户端会向对象池中请求一个对象，然后使用这个返回的对象执行相关操作。当客户端使用完毕，它将把这个特定类型的工厂对象返回给对象池，而不是销毁掉这个对象。

在初始化实例成本高，实例化率高，可用实例不足的情况下，对象池可以极大地提升性能。在创建对象（尤其是通过网络）时间花销不确定的情况下，通过对象池在可期时间内就可以获得所需的对象。

无论如何，对象池模式在需要耗时创建对象方面，例如创建数据库连接，套接字连接，线程和大型图形对象（比方字体或位图等），使用起来都是大有裨益的。在某些情况下，简单的对象池（无外部资源，只占内存）可能效率不高，甚至会有损性能。

原型模式：
相比正常创建一个对象 ( new Foo() )，首先创建一个原型，然后克隆它会更节省开销。

简单工厂模式：
简单工厂模式是一个精简版的工厂模式。

它与静态工厂模式最大的区别是它不是『静态』的。因为非静态，所以你可以拥有多个不同参数的工厂，你可以为其创建子类。甚至可以模拟（Mock）他，这对编写可测试的代码来讲至关重要。 这也是它比静态工厂模式受欢迎的原因。

单例模式：

在应用程序调用的时候，只能获得一个对象实例。

静态工厂模式：
与抽象工厂模式类似，此模式用于创建一系列相关或相互依赖的对象。 『静态工厂模式』与『抽象工厂模式』的区别在于，只使用一个静态方法来创建所有类型对象， 此方法通常被命名为 factory 或 build。

结构型：
适配器模式：
将一个类的接口转换成可应用的兼容接口。适配器使原本由于接口不兼容而不能一起工作的那些类可以一起工作。

桥梁模式：
将抽象与实现分离，这样两者可以独立地改变。

组合模式：
一组对象与该对象的单个实例的处理方式一致。

数据映射模式：
数据映射器是一种数据访问层，它执行持久性数据存储（通常是关系数据库）和内存数据表示（域层）之间的数据双向传输。 该模式的目标是保持内存表示和持久数据存储相互独立，并保持数据映射器本身。 该层由一个或多个映射器（或数据访问对象）组成，执行数据传输。 映射器实现的范围有所不同。 通用映射器将处理许多不同的域实体类型，专用映射器将处理一个或几个。

这种模式的关键点在于，与活动记录模式不同，数据模型遵循单一责任原则。

装饰模式：
为类实例动态增加新的方法。

依赖注入模式：
用松散耦合的方式来更好的实现可测试、可维护和可扩展的代码。

门面模式：
门面模式的最初目的并不是为了避免让你阅读复杂的 API 文档，这只是一个附带作用。其实它的本意是为了降低耦合性并且遵循 Demeter 定律。

一个门面旨在通过嵌入许多（但有时只有一个）接口来分离客户端和子系统。当然，也是为了降低复杂度。

门面不会禁止你访问子系统。
你可以（应该）有多个门面对应一个子系统。
这就是为什么一个好的门面里没有 new 的原因。如果每个方法都有多种创建，那并不是一个门面，而是一个构建器 [抽象的|静态的|简单的] 或是一个工厂 [方法] 。

最好的门面是没有 new 的，并且其构造函数带有接口类型提示的参数。 如果你需要创建新的实例，可以使用工厂作为变量。

流接口模式：
用来编写易于阅读的代码，就像自然语言一样（如英语）。

享元模式：
为了节约内存的使用，享元模式会尽量使类似的对象共享内存。在大量类似对象被使用的情况中这是十分必要的。常用做法是在外部数据结构中保存类似对象的状态，并在需要时将他们传递给享元对象。

代理模式：
链接任何具有高价值或无法复制的代码。

注册模式：
目的是能够存储在应用程序中经常使用的对象实例，通常会使用只有静态方法的抽象类来实现（或使用单例模式）。需要注意的是这里可能会引入全局的状态，我们需要使用依赖注入来避免它。

行为型：
责任链模式：
建立一个对象链来按指定顺序处理调用。如果其中一个对象无法处理命令，它会委托这个调用给它的下一个对象来进行处理，以此类推。

命令行模式：
为了封装调用和解耦。

我们有一个调用程序和一个接收器。 这种模式使用「命令行」将方法调用委托给接收器并且呈现相同的「执行」方法。 因此，调用程序只知道调用「执行」去处理客户端的命令。接收器会从调用程序中分离出来。

这个模式的另一面是取消方法的 execute()，也就是 undo() 。命令行也可以通过最小量的复制粘贴和依赖组合（不是继承）被聚合，从而组合成更复杂的命令集。

迭代器模式：
让对象变得可迭代并表现得像对象集合。

中介者模式：
本模式提供了一种轻松的多组件之间弱耦合的协同方式。如果你有个“情报中心”，观察者模式也是个好选择，类似于控制器（并非 MVC 意义上的控制器）。

所有关联协同的组件（称作 Colleague）仅与 MediatorInterface 接口建立耦合，面向对象编程中这是好事，一个良友胜于有多个朋友。这是该模式的重要特性。

备忘录模式：
空对象模式不属于 GoF 设计模式，但是它作为一种经常出现的套路足以被视为设计模式了。它具有如下优点：

客户端代码简单
可以减少报空指针异常的几率
测试用例不需要考虑太多条件
返回一个对象或 null 应该用返回对象或者 NullObject 代替。NullObject 简化了死板的代码，消除了客户端代码中的条件检查，例如 if (!is_null($obj)) { $obj->callSomething(); } 只需$obj->callSomething(); 就行。

空对象模式：
当对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。它使用的是低耦合的方式。

观察者模式：
当对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。它使用的是低耦合的方式。

规格模式：
构建一个清晰的业务规则规范，其中每条规则都能被针对性地检查。每个规范类中都有一个称为isSatisfiedBy的方法，方法判断给定的规则是否满足规范从而返回 true 或 false。

状态模式：
状态模式可以基于一个对象的同种事务而封装出不同的行为。它提供一种简洁的方式使得对象在运行时可以改变自身行为，而不必借助单一庞大的条件判断语句。

策略模式：
分离「策略」并使他们之间能互相快速切换。此外，这种模式是一种不错的继承替代方案（替代使用扩展抽象类的方式）。

模板方法模式：

模板方法模式是一种行为型的设计模式。

可能你已经见过这种模式很多次了。它是一种让抽象模板的子类「完成」一系列算法的行为策略。

众所周知的「好莱坞原则」：「不要打电话给我们，我们会打电话给你」。这个类不是由子类调用的，而是以相反的方式。怎么做？当然很抽象啦！

换而言之，它是一种非常适合框架库的算法骨架。用户只需要实现子类的一种方法，其父类便可去搞定这项工作了。

这是一种分离具体类的简单办法，且可以减少复制粘贴，这也是它常见的原因。

访问者模式：
访问者模式可以让你将对象操作外包给其他对象。这样做的最主要原因就是关注（数据结构和数据操作）分离。但是被访问的类必须定一个契约接受访问者。
契约可以是一个抽象类也可直接就是一个接口。在此情况下，每个访问者必须自行选择调用访问者的哪个方法。

更多类型：
委托模式：
在委托模式的示例里，一个对象将它要执行的任务委派给与之关联的帮助对象去执行。在示例中，「组长」声明了 writeCode 方法并使用它，其实「组长」把 writeCode 委托给「菜鸟开发者」的 writeBadCode 方法做了。这种反转责任的做法隐藏了其内部执行 writeBadCode 的细节。

服务定位器模式：
服务定位器模式被认为是一种反面模式！
服务定位器模式被一些人认为是一种反面模式。它违反了依赖倒置原则。该模式隐藏类的依赖，而不是暴露依赖（如果暴露可通过依赖注入的方式注入依赖）。当某项服务的依赖发生变化时，使用该服务的类的功能将面临被破坏的风险，最终导致系统难以维护。

资源库模式：
该模式通过提供集合风格的接口来访问领域对象，从而协调领域和数据映射层。 资料库模式封装了一组存储在数据存储器里的对象和操作它们的方面，这样子为数据持久化层提供了更加面向对象的视角。资料库模式同时也达到了领域层与数据映射层之间清晰分离，单向依赖的目的。

实体属性值模式:
实体属性值模型（Entity-attribute-value EAV）是一种用数据模型描述实体的属性（属性，参数），可以用来形容他们潜在巨大，但实际上将适用于给定的实体的数量是相对较少。 在数学中，这种模式被称为一个稀疏矩阵 。 EAV也被称为对象的属性值的模式，垂直的数据库模型和开放式架构。