设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

本教程将以php语言为基础讲解在php中如何实现各种常见的设计模式。

一、设计模式相关知识

1.1、设计模式概述

①、设计模式（Design pattern）

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

②、为什么要提倡设计模式 (Design Pattern)呢？

根本原因是为了代码复用，增加可维护性。

那么怎么才能实现代码复用呢？面向对象有几个原则：开闭原则（Open Closed Principle，OCP）、里氏代换原则（Liskov Substitution Principle，LSP）、依赖倒转原则（Dependency Inversion Principle，DIP）、接口隔离原则（Interface Segregation Principle，ISP）、合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）、最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。

设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

③、23种模式

设计模式分为三种类型，共23种:

• Abstract Factory（抽象工厂模式）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

• Adapter（适配器模式）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

• Bridge（桥接模式）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。

• Builder（建造者模式）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

• Chain of Responsibility（职责链模式）：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

• Command（命令模式）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。

• Composite（组合模式）：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。

• Decorator（装饰模式）：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。

• Facade（外观模式）：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

• Factory Method（工厂模式）：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。

• Flyweight（享元模式）：运用共享技术有效地支持大量细粒度的对象。

• Interpreter（解析器模式）：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。

• Iterator（迭代器模式）：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

• Mediator（中介模式）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

• Memento（备忘录模式）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。

• Observer（观察者模式）：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。

• Prototype（原型模式）：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

• Proxy（代理模式）：为其他对象提供一个代理以控制对这个对象的访问。

• Singleton（单例模式）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 单例模式是最简单的设计模式之一，但是对于Java的开发者来说，它却有很多缺陷。在九月的专栏中，David Geary探讨了单例模式以及在面对多线程（multi-threading）、类装载器（class loaders）和序列化（serialization）时如何处理这些缺陷。

• State（状态模式）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。

• Strategy（策略模式）：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。

• Template Method（模板方法模式）：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

• Visitor（访问者模式）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

1.2、开闭原则

①、开闭原则

开闭原则（OCP）是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。

1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。这句话说得略微有点专业，我们把它讲得更通俗一点，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。

遵循开闭原则设计出的模块具有两个主要特征：

• 对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。

• 对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

②、实现方法

实现开闭原则的关键就在于“抽象”。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需修改；同时，由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。

我们在软件开发的过程中，一直都是提倡需求导向的。这就要求我们在设计的时候，要非常清楚地了解用户需求，判断需求中包含的可能的变化，从而明确在什么情况下使用开闭原则。

关于系统可变的部分，还有一个更具体的对可变性封装原则（Principle of Encapsulation of Variation, EVP），它从软件工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。

我们在实际开发过程的设计开始阶段，就要罗列出来系统所有可能的行为，并把这些行为加入到抽象底层，根本就是不可能的，这么去做也是不经济的。因此我们应该现实的接受修改拥抱变化，使我们的代码可以对扩展开放，对修改关闭。

③、好处

如果一个软件系统符合开闭原则的，那么从软件工程的角度来看，它至少具有这样的好处：

• 可复用性好。

• 我们可以在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。

• 可维护性好。

• 由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。

1.3、里氏代换原则

里氏替换原则LSP讲的是基类和子类的关系。只有当这种关系存在时，里氏代换关系才存在。如果两个具体的类A，B之间的关系违反了LSP的设计，(假设是从B到A的继承关系)那么根据具体的情况可以在下面的两种重构方案中选择一种。

①、举例

//举例说明继承的风险，我们需要完成一个两数相减的功能，由类A来负责。
class a{
public $width;
public $height;
public function func1($a, $b){  
        return $a - $b;  
    }
}
$a = new a();
echo $a->func1(100,50);
//运行结果100-50=50

后来，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：

采用类B继承类A代码如下：

class b extends a{  
    public function func1($a, $b){  
        return $a + $b;
    }  
      
    public function func2($a, $b){  
        return $this->func1($a, $b) + 100;
    } 
}
$b = new b();
echo $b->func2(100, 50);

假设类B在给方法起名时无意中重写了父类的方法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能fun1出现了错误(错误的原因是减法变成了加法而其他使用者并不知道。别总想着代码是一个人写的呦！还有大家没有时间去逐行读你的代码，他们只是按照规则进行应用)。

②、原则

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

• 子类中可以增加自己特有的方法。

• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

看上去很不可思议，因为我们会发现在自己编程中常常会违反里氏替换原则，程序照样跑的好好的。所以大家都会产生这样的疑问，假如我非要不遵循里氏替换原则会有什么后果？

后果就是：你写的代码出问题的几率将会大大增加。

1.4、接口隔离原则

①、概念

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

使用多个专门的接口比使用单一的总接口要好。

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

②、例子

这个图的意思是：类A依赖接口I中的方法1、方法2、方法3，类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5，类D是对类C依赖的实现。对于类B和类D来说，虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口，拆分后的设计如图所示

接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。

③、注意事项

采用接口隔离原则对接口进行约束时，要注意以下几点：

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。

• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。

• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

• 运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则

二、创建型模型

2.1、工厂模式

工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一种模式。著名的Jive论坛 ,就大量使用了工厂模式，工厂模式在Java程序系统可以说是随处可见。因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A()。

工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑使用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。

//汽车类
class car{
    public function run(){
		echo 'car run .....';
    }	
}
class bus{
    public function run(){
        echo 'bus run .....';
    }	
}
//创建一个汽车工厂类用于生产汽车对象
class carFactory{
    public static function getACar($type){
		if($type == 'car'){
			return new car();
		}else{
			return new bus();
		}	
    }
}
//调用演示
$car = carFactory::getACar('bus');
$car->run();

随着项目的深入,bus类和car类可能还会"生出很多儿子出来", 那么我们要对这些儿子一个个实例化,更糟糕的是,可能还要对以前的代码进行修改，如修改了car的类名称或者文件名称或为car或bus设置了构造函数，如果我们不使用工程模式我们将需要修改对应的调用文件及代码（忘记了怎么吧 出现bug！！）。

但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了。

2.2、单例模式

单例模式是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例类的特殊类。通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问，从而方便对实例个数的控制并节约系统资源。如果希望在系统中某个类的对象只能存在一个，单例模式是最好的解决方案。

如何保证一个类只有一个实例并且这个实例易于被访问呢？定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象。一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。

例如我们在php的开发过程中我们创建了一个db类（数据库操作类），那么我们希望再一个php文件中一个数据库只被连接一次而一个php文件中也只需要一个数据库对象！因为多次连接数据库会大大降低php的执行效率。也会带来极大的系统开销！

使用单例模式来封装你的数据库吧^_^

class db
{
	//使用一个静态变量记录db对象初始化时为null
	public static $db = null;

	/* 
	 * 私有构造函数是类无法完成外部的调用
	 * 意味着您将无法使用 $xx = new db();
	 */
	private function __construct(){
		echo '连接数据库....';
	}

	/* 
	 * 使用静态方法去获取数据对象
	 * 获取时先判断db对象是否已经存在，如果存在则直接返回db对象反正则创建这个对象
	 */
	public static function getInstance(){
		if(self::$db == null){
			self::$db = new db();
		}
		return self::$db;
	}

	public function query($sql){
		echo '执行sql命令';
	}

	public function __destruct(){
		echo '关闭数据库连接....';
	}
}

$db = db::getInstance();
$db1 = db::getInstance();
$db->query('test');
$db2 = db::getInstance();
//输出 : 连接数据库....执行sql命令关闭数据库连接....

可以看到不论我们获取多少次db对象，虽然他们名称不同，但都代表着同一个对象！这样就实现单例模式！

2.3、建造者模式

建造者模式是对象的创建模式。它可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。

由于建造零件的过程很复杂，因此，这些零件的建造过程往往被“外部化”到另一个乘坐建造者的对象里，建造者对象返还给客户端的是一个全部零件都建造完毕的产品对象。它将产品的结构和建造过程对客户端隐藏起来。

建造模式的四种角色：

builder：为创建一个产品对象的各个部件指定抽象接口。

ConcreteBuilder：实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，并提供一个检索产品的接口。

Director：构造一个使用Builder接口的对象。

Product：表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程，包含定义组成部件的类，包括将这些部件装配成最终产品的接口。

/**
 * 产品,包含产品类型、价钱、颜色属性
 */
class Product
{
	public $_type  = null;
	public $_price = null;
	public $_color = null;
 
	public function setType($type){
		echo '设置产品类型';
		$this->_type = $type;
	}
 
	public function setPrice($price){
		echo '设置产品价格,';
		$this->_price = $price;
	}
 	
 	public function setColor($color){
		echo '设置产品颜色';
		$this->_color = $color;
	}
} 
//不使用builder模式
$product = new Product();
$product->setType("衣服");
$product->setPrice("100");
$product->setColor("红色");
 
//使用builder模式
class ProductBuilder{
	public $_config = null;
	public $_object = null;
	//$config 被设计为一个数组，格式
	//$config = array('type' => 'xx', 'price' => 'xx', 'color' => 'xx');
	public function ProductBuilder($config){
		$this->_object = new Product();
		$this->_config = $config;
	}
 
	public function build(){
		echo '
使用建造者模式:
';
		$this->_object->setType($this->_config['type']);
		$this->_object->setPrice($this->_config['price']);
		$this->_object->setColor($this->_config['color']);
	}
 
	public function getProduct(){
		return $this->_object;
	}
}

$config = array('type' => '汽车', 'price' => '2000000', 'color' => '白色');
$objBuilder = new ProductBuilder($config);
$objBuilder->build();
$objProduct = $objBuilder->getProduct();
echo '
';
var_dump($objProduct);

①、建造者模式的优点

• 首先，建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在导演类中对整体而言可以取得比较好的稳定性。

• 其次，建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。

②、建造者模式与工厂模式的区别

我们可以看到，建造者模式与工厂模式是极为相似的，总体上，建造者模式仅仅只比工厂模式多了一个“导演类”的角色。在建造者模式的类图中，假如把这个导演类看做是最终调用的客户端，那么图中剩余的部分就可以看作是一个简单的工厂模式了。

与工厂模式相比，建造者模式一般用来创建更为复杂的对象，因为对象的创建过程更为复杂，因此将对象的创建过程独立出来组成一个新的类——导演类。也就是说，工厂模式是将对象的全部创建过程封装在工厂类中，由工厂类向客户端提供最终的产品；而建造者模式中，建造者类一般只提供产品类中各个组件的建造，而将具体建造过程交付给导演类。由导演类负责将各个组件按照特定的规则组建为产品，然后将组建好的产品交付给客户端。

③、总结

建造者模式与工厂模式类似，他们都是建造者模式，适用的场景也很相似。一般来说，如果产品的建造很复杂，那么请用工厂模式；如果产品的建造更复杂，那么请用建造者模式。

2.4、原型模式

①、什么是原型模式

Prototype原型模式是一种创建型设计模式，Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节,工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建。

②、解决什么问题

它主要面对的问题是：“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。

使用php提供的clone()方法来实现对象的克隆，所以Prototype模式实现一下子变得很简单。并可以使用php的__clone() 函数完成深度克隆。

③、代码实例

//定义原型类接口
interface prototype{
	public function copy();
}
//一个具体的业务类并实现了prototype 接口
//以一个文本的读写操作类为例
class text implements prototype{
	private $_fileUrl;

	public function __construct($fileUrl){
		$this->_fileUrl = $fileUrl;
	}

	public function write($content){
		file_put_contents($this->_fileUrl, $content);
	}

	public function read(){
		return file_get_contents($this->_fileUrl);
	}

	public function copy(){
		return clone $this;
	}

	/* 可以使用php的__clone() 函数完成深度克隆 */
	public function __clone(){
		echo 'clone...';
	}
}

$texter1 = new text('1.txt');
$texter1->write('test...');
//获得一个原型
$texter2 = $texter1->copy();
echo $texter2->read();

三、结构型模式

3.1、适配器模式

①、什么是适配器模式 (Adapter Pattern)

Adapter模式也叫适配器模式，是构造型模式之一，通过Adapter模式可以改变已有类（或外部类）的接口形式。

②、适配器模式应用场景

在大规模的系统开发过程中，我们常常碰到诸如以下这些情况：

我们需要实现某些功能，这些功能已有还不太成熟的一个或多个外部组件，如果我们自己重新开发这些功能会花费大量时间；所以很多情况下会选择先暂时使用外部组件，以后再考虑随时替换。但这样一来，会带来一个问题，随着对外部组件库的替换，可能需要对引用该外部组件的源代码进行大面积的修改，因此也极可能引入新的问题等等。如何最大限度的降低修改面呢？Adapter模式就是针对这种类似需求而提出来的。Adapter模式通过定义一个新的接口（对要实现的功能加以抽象），和一个实现该接口的Adapter（适配器）类来透明地调用外部组件。这样替换外部组件时，最多只要修改几个Adapter类就可以了，其他源代码都不会受到影响。

③、php实例

假设我们有一个文章类已经完成了文章的列表及详细信息展示工作：

class article{
	//文章列表获取方法
	public function getLIst(){
		echo '获取文章列表';
	}
	//根据文章id获取文章的标题和内容
	public function getInfo($id){
		echo '根据文章id获取文章的标题和内容';
	}
}
$art = new article();
$art->getInfo(1);

由于项目的需要，现在需要这样的一个功能。获取文章细节时还需要获取文章的创建时间，并需要更新文章的阅读次数。

如果不使用适配器模式我们首先想到的时修改article类的源代码增加这样的功能。之所以这样想是因为上面的例子代码很简单，如果他是上千行呢？如果getInfo()代码非常复杂呢？

使用适配器模式来解决这一切吧！

class articleAdapter{
	public $_artObj;

	public function __construct($artObj){
		$this->_artObj = $artObj;
	}

	public function getInfo($id){
		$this->_artObj->getInfo($id);
	}

	public function getInfoAndUpdate($id){
		//利用$this->_artObj查询符合要求的文章数据并更新浏览次数
		echo '$this->_artObj查询符合要求的文章数据并更新浏览次数';
	}
}

$art = new articleAdapter(new article());
$art->getInfo(12);
$art->getInfoAndUpdate(12);

④、为什么不使用继承？

对象适配器：不是通过继承的方式，而是通过对象组合的方式来进行处理的，我们只要学过OO的设计原则的都知道，组合相比继承是推荐的方式。

类适配器：通过继承的方式来实现，将旧系统的方法进行封装。对象适配器在进行适配器之间的转换过程中，无疑类适配器也能完成，但是依赖性会加大，并且随着适配要求的灵活性，可能通过继承膨胀的难以控制。

一般来说类适配器的灵活性较差，对象适配器较灵活，是我们推荐的方式，可以通过依赖注入的方式，或者是配置的方式来做。类适配器需要继承自要适配的旧系统的类，无疑这不是一个好的办法。

3.2、组合模式 (Composite Pattern)

①、什么是组合模式

组合模式：允许客户将对象组合成树形结构来表现"整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

组合模式让我们能用树形方式创建对象的结构，树里面包含了组合以及个别的对象。使用组合结构，我们能把相同的操作应用在组合和个别对象上。换句话说，在大多数情况下，我们可以忽略对象组合和个别对象之间的差别。

包含其他组件的组件为组合对象；不包含其他组件的组件为叶节点对象。

组合模式为了保持”透明性“，常常会违反单一责任原则。也就是说，它一方面要管理内部对象，另一方面要提供一套访问接口。

当组合模式接口里提供删除子节点的方法时，在组件里有一个指向父节点的指针的话，实现删除操作会比较容易。

②、以一个军队的战斗力计算为例演示组合模式

军队由步兵、炮兵、特种兵组成，他们都具备一个能力就是战斗并具备各自的战斗力。我们通过他们组合成一个军队并完成战斗力的计算。

//抽象士兵类
interface soldier{
	public function fire();
}
//步兵 攻击力5
class bubing implements soldier{
	public function fire(){
		return 5;
	}
}
//炮兵 攻击力8
class paobing implements soldier{
	public function fire(){
		return 8;
	}
}
//特种兵 攻击力 12
class tezhongbing implements soldier{
	public function fire(){
		return 12;
	}
}
//军队类实现兵种的组合
class arm{
	//存储作战兵种的数组 
	private $soldier = array();
	//添加作战兵种
	public function add($soldierType){
		//获取对应的兵种对象
		$soldier  = new $soldierType();
		//保存进数组利用数组的键记录兵种 便于删除
		$this->soldier[$soldierType] = $soldier;
	}
	//删除兵种
	public function delete($soldierType){
		if(isset($this->soldier[$soldierType])){
			unset($this->soldier[$soldierType]);
		}
	}
	//计算并输出战斗能力
	public function show(){
		$zhantouli = 0;
		foreach($this->soldier as $v){
			$zhandouli += $v->fire();
		}
		echo "军队的战斗力: ".$zhandouli;
	}
}

$arm = new arm();
$arm->add('bubing');
$arm->add('paobing');
$arm->show();
$arm->delete('paobing');
$arm->show();

3.3、外观模式（门面模式）

①、什么是外观模式

外观模式是指通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。

②、外观模式的优点

• 它对客户屏蔽了子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便

• 实现了子系统与客户之间的松耦合关系

• 如果应用需要，它并不限制它们使用子系统类。因此可以在系统易用性与能用性之间加以选择

③、外观模式的适用场景

• 为一些复杂的子系统提供一组接口

• 提高子系统的独立性

• 在层次化结构中，可以使用门面模式定义系统的每一层的接口

④、例子

比如我们在网站开发中有以下几个功能

关闭和开启网站、关闭开启博客、关闭开启注册3个功能我们可以将他们实现后并包装起来。

//关闭和开启网站 
class webSet{
	public function start(){
		echo '开启网站......';
	}
	public function stop(){
		echo '关闭网站......';
	}
}
//关闭开启博客 
class blogSet{
	public function start(){
		echo '开启博客......';
	}
	public function stop(){
		echo '关闭博客......';
	}
}
//关闭开启注册
class registerSet{
	public function start(){
		echo '开启注册......';
	}
	public function stop(){
		echo '关闭注册......';
	}
}

//门面类
class Facade{
	//网站设置对象
	private $webSet;
	//博客设置对象
	private $blogSet;
	//注册功能设置对象
	private $registerSet;

	public function __construct(){
		$this->webSet        = new webSet();
		$this->blogSet       = new blogSet();
		$this->registerSet   = new registerSet();
	}

	//设置共开关 - 开
	public function turnOn(){
		$this->webSet->start();
		$this->blogSet->start();
		$this->registerSet->start();
	}

	//设置共开关 - 关
	public function turnOff(){
		$this->webSet->stop();
		$this->blogSet->stop();
		$this->registerSet->stop();
	}
}

//调用
$Facade = new Facade();
$Facade->turnOn();

3.4、代理模式

代理模式的作用和继承以及接口和组合的作用类似,都是为了聚合共用部分,减少公共部分的代码。

不同的是相比起继承,他们的语境不同,继承要表达的含义是 is-a, 而代理要表达的含义更接近于接口, 是 has-a,而且使用代理的话应了一句话"少用继承,多用组合",要表达的意思其实也就是降低耦合度了。

对于组合来说，他比组合更具灵活性，比如我们将代理对象设为private，那么我可以选择只提供一部分的代理功能，例如Printer的某一个或两个方法，又或者在提供Printer的功能的时候加入一些其他的操作，这些都是可以的。

//代理对象,一台打印机
class Printer { 
    public function printSth() {
        echo '我可以打印
';
    }
}
//这是一个文印处理店,只文印,卖纸,不照相
class TextShop {
    private $printer;
    public function __construct(Printer $printer) {
        $this->printer = $printer;
    }
    //卖纸
    public function sellPaper() {
        echo 'give you some paper 
';
    }
    //将代理对象有的功能交给代理对象处理
    public function __call($method, $args) {
        if(method_exists($this->printer, $method)) {
            $this->printer->$method($args);
        }
    }
}

//这是一个照相店,只文印,拍照,不卖纸
class PhotoShop {    
    private $printer;
    
    public function __construct(Printer $printer) {
        $this->printer = $printer;
    }
    
    public function takePhotos() {    //照相
        echo 'take photos for you 
';
    }
    
    public function __call($method, $args) {    //将代理对象有的功能交给代理对象处理
        if(method_exists($this->printer, $method)) {
            $this->printer->$method($args);
        }
    }
}

$printer = new Printer();
$textShop = new TextShop($printer);
$photoShop = new PhotoShop($printer);

$textShop->printSth();
$photoShop->printSth();

3.5、装饰模式

①、什么是装饰模式

在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。它是通过创建一个包装对象，也就是装饰来包裹真实的对象。

②、装饰模式的特点

• 装饰对象和真实对象有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对象交互。

• 装饰对象包含一个真实对象的引用（reference）

• 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。

• 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展。

③、优点

• Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。

• 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

④、缺点

• 这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。

• 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。

• 装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

⑤、php代码实例

抽象一个工人类具有工作方法，2个子类（水管工、木工）实现了工人接口：

interface worker{
	public function doSomeWork();
}
//水管工
class shuiguan implements worker{
	public function doSomeWork(){
		echo '修水管';
	}
}
//木工
class mu implements worker{
	public function doSomeWork(){
		echo '修门窗';
	}
}

现在有新的需求a公司的工人（包含水管、木工）进门要求先说“您好！”，我们想在不影响基础类的情况下统一实现这个功能。我们可以使用装饰模式类实现：

//a公司工人
class aWorker implements worker{
	//具体的工人
	public $worker;
	//构造函数获取工人
	public function __construct($worker){
		$this->worker  = $worker;
	}
	public function doSomeWork(){
		echo '您好!';
		$this->worker->doSomeWork();
	}
}

$aWorker = new aWorker(new shuiguan());
$aWorker->doSomeWork();

aWorker 同样实现了worker类的接口，它需要一个具体的工人对象，在执行完特殊要求（说您好）后使用原有工人对象的方法。这就是装饰模式！