代理模式 Proxy

目的

代理模式（Proxy）为其他对象提供一种代理以控制对这个对象的访问。使用代理模式创建代理对象，让代理对象控制目标对象的访问（目标对象可以是远程的对象、创建开销大的对象或需要安全控制的对象），并且可以在不改变目标对象的情况下添加一些额外的功能。在某些情况下，一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用，并且可以通过代理对象去掉客户不能看到的内容和服务或者添加客户需要的额外服务。经典例子就是网络代理，你想访问
Facebook 或者 Twitter ，如何绕过 GFW(Great FireWall, 防火长城)？找个代理网站。

应用场景

  • Doctrine2 使用代理来实现框架的 “魔术”（例如：延迟加载），而用户仍然使用他们自己的实体类且不会使用到代理

UML图

Proxy

装饰模式 Decorator

目的

为类实例动态增加新的方法。

应用场景

  • Zend Framework: Zend_Form_Element 实例的装饰者
  • Web Service Layer: 用于 REST 服务的 JSON 和 XML 装饰者 (当然，在这个例子中理应只有一个是被允许的)

UML图

Decorator

适配器模式 Adapter

目的

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

应用场景

  • 客户端数据库适配器
  • 使用多个不同的网络服务和适配器来规范数据，使得出的结果是相同的

UML图

Adapter

组合模式 Composite

目的

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

应用场景

  • 一个表单类实例在处理其表单所有元素的方法与处理该表单自身实例方法相同，在调用方法 render() 时，会随之遍历它的所有子元素并对他们调用 render() 方法
  • Zend_Config: 一个配置选项树，每个选项自身就是一个 Zend_Config 对象

UML图

Composite

桥梁模式 Bridge

目的

将抽象和实现分离，这样两者可以独立地改变。

应用场景

  • Symfony 学术桥梁

UML图

Bridge

门面模式 Facade

目的

门面模式的最初目的并不是为了避免让你阅读复杂的 API 文档，这只是一个附带作用。其实它的本意是为了降低耦合性并且遵循 Demeter 定律（得墨忒耳定律，亦称为 “最少知识原则”
）。一个门面旨在通过嵌入许多（但有时只有一个）接口来分离客户端和子系统。当然，也是为了降低复杂度。门面不会禁止你访问子系统。你可以（应该）有多个门面对应一个子系统。这就是为什么一个好的门面里没有 new
的原因。如果每个方法都有多种创建，那并不是一个门面，而是一个构建器 抽象的 | 静态的 | 简单的 或是一个工厂 方法
。最好的门面是没有new的，并且其构造函数带有接口类型提示的参数。如果你需要创建新的实例，可以使用工厂作为变量。

UML图

Facade

享元模式 Flyweight

目的

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

UML图

Flyweight