将一个类的接口转换成客户希望的另外一个接口，Adapter模式使得原来由于接口不兼容而不能一起工作的那此类可以一起工作。本文主要和大家分享适配器的详解，希望能帮助到大家。
主要角色
目标角色：定义客户端使用的与特定领域相关的接口，这就是我们所期待得到的
源角色：需要进行适配的接口
适配器角色：对Adaptee的接口与target接口进行适配；适配器是本模式的核心，适配器把源接口转成目标接口，此角色为具体的类
适用性
1、你想使用一个已经存在的类，而它的接口不符合你的需求
2、你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作
立即学习“PHP免费学习笔记（深入）”；
3、你想要一个已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口（仅限于对象适配器）
//目标角色
interface Target {
public function simpleMethod1();
public function simpleMethod2();
}
//源角色
class Adaptee {
public function simpleMethod1(){
echo 'Adapter simpleMethod1'."
";
}
}
//类适配器角色
class Adapter implements Target {
private $adaptee;
function __construct(Adaptee $adaptee) {
$this->adaptee = $adaptee;
}
//委派调用Adaptee的sampleMethod1方法
public function simpleMethod1(){
echo $this->adaptee->simpleMethod1();
}
public function simpleMethod2(){
echo 'Adapter simpleMethod2'."
";
}
}
//客户端
class Client {
public static function main() {
$adaptee = new Adaptee();
$adapter = new Adapter($adaptee);
$adapter->simpleMethod1();
$adapter->simpleMethod2();
}
}
Client::main();也许上述这么讲，你们还不知道什么是适配器。那么接下来，我再详细的讲解一下
什么时候使用适配器模式呢？
其实最简单的一个例子就是使用第三方类库。这些类库都会随着版本的升级，对应的api也会改变。当接口发生改变的时候，适配器就派上用场了
我举一个实际的例子吧
一开始的和谐
黑枣玩具公司专门生产玩具，生产的玩具不限于狗、猫、狮子，鱼等动物。每个玩具都可以进行“张嘴”与“闭嘴”操作，分别调用了openMouth与closeMouth方法。 在这个时候，我们很容易想到可以第一定义一个抽象类Toy,甚至是接口Toy,这些问题不大，其他的类去继承父类，实现父类的方法。一片和谐，信心向荣。
平滑的破坏
为了扩大业务，现在黑枣玩具公司与红枣遥控公司合作，红枣遥控公司可以使用遥控设备对动物进行嘴巴控制。不过红枣遥控公司的遥控设备是调用的动物的doMouthOpen及doMouthClose方法。黑枣玩具公司的程序员现在必须要做的是对Toy系列类进行升级改造，使Toy能调用doMouthOpen及doMouthClose方法。
考虑实现的方法时，我们很直接地想到，你需要的话我再在我的父类子类里给你添加这么两个方法就好啦。当你一次又一次在父类子类里面重复添加着这两个方法的时候，总会想着如此重复的工作，难道不能解决么？当有数百个子类的时候，程序员会改疯的。程序员往往比的是谁在不影响效率的时候更会“偷懒”。这样做下去程序员会觉得自己很傻。(其实我经常当这样的傻子)
模板采用响应式设计，自动适应手机，电脑及平板显示；满足单一店铺外卖需求。功能：1.菜单分类管理2.菜品管理：菜品增加，删除，修改3.订单管理4.友情链接管理5.数据库备份6.文章模块：如：促销活动，帮助中心7.单页模块：如：企业信息，关于我们更强大的功能在开发中……安装方法：上传到网站根目录，运行http://www.***.com/install 自动
abstract class Toy
{
public abstract function openMouth();
public abstract function closeMouth();
//为红枣遥控公司控制接口增加doMouthOpen方法
public abstract function doMouthOpen();
//为红枣遥控公司控制接口增加doMouthClose方法
public abstract function doMouthClose();
}
class Dog extends Toy
{
public function openMouth()
{
echo "Dog open Mouth\n";
}
public function closeMouth()
{
echo "Dog open Mouth\n";
}
//增加的方法
public function doMouthOpen()
{
$this->doMouthOpen();
}
//增加的方法
public function doMouthClose()
{
$this->closeMouth();
}
}
class Cat extends Toy
{
public function openMouth()
{
echo "Cat open Mouth\n";
}
public function closeMouth()
{
echo "Cat open Mouth\n";
}
//增加的方法
public function doMouthOpen()
{
$this->doMouthOpen();
}
//增加的方法
public function doMouthClose()
{
$this->closeMouth();
}
}更加烦躁
程序员刚刚码完代码，喝了口水，突然间另一个消息传来。 黑枣玩具公司也要与绿枣遥控公司合作，因为绿枣遥控公司遥控设备更便宜稳定。不过绿枣遥控公司的遥控设备是调用的动物的operMouth(type)方法来实现嘴巴控制。如果type为0则“闭嘴”，反之张嘴。 这下好了，程序员又得对Toy及其子类进行升级，使Toy能调用operMouth()方法。搁谁都不淡定了。
abstract class Toy
{
public abstract function openMouth();
public abstract function closeMouth();
public abstract function doMouthOpen();
public abstract function doMouthClose();
//为绿枣遥控公司控制接口增加doMouthClose方法
public abstract function operateMouth($type = 0);
}
class Dog extends Toy
{
public function openMouth()
{
echo "Dog open Mouth\n";
}
public function closeMouth()
{
echo "Dog open Mouth\n";
}
public function doMouthOpen()
{
$this->doMouthOpen();
}
public function doMouthClose()
{
$this->closeMouth();
}
public function operateMouth($type = 0)
{
if ($type == 0) {
$this->closeMouth();
} else {
$this->operateMouth();
}
}
}
class Cat extends Toy
{
public function openMouth()
{
echo "Cat open Mouth\n";
}
public function closeMouth()
{
echo "Cat open Mouth\n";
}
public function doMouthOpen()
{
$this->doMouthOpen();
}
public function doMouthClose()
{
$this->closeMouth();
}
public function operateMouth($type = 0)
{
if ($type == 0) {
$this->closeMouth();
} else {
$this->operateMouth();
}
}
}在这个时候，程序员必须要动脑子想办法了，就算自己勤快，万一哪天紫枣青枣黄枣山枣这些遥控公司全来的时候，忽略自己不断增多的工作量不说，这个Toy类可是越来越大，总有一天程序员不崩溃，系统也会崩溃。
问题出在哪里呢
像上面那样编写代码，代码实现违反了“开-闭”原则，一个软件实体应当对扩展开放，对修改关闭。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。也就是说每个尸体都是一个小王国，你让我参与你的事情这个可以，但你不能修改我的内部，除非我的内部代码确实可以优化。
在这种想法下，我们懂得了如何去用继承，如何利用多态，甚至如何实现“高内聚，低耦合”。
回到这个问题，我们现在面临这么一个问题，新的接口方法我要实现，旧的接口（Toy抽象类）也不能动，那么总得有个解决方法吧。那就是引入一个新的类--我们本文的主角--适配器。 适配器要完成的功能很明确，引用现有接口的方法实现新的接口的方法。更像它名字描述的那样，你的接口不改的话，我就利用现有接口和你对接一下吧。
到此，解决方法已经呼之欲出了，下面贴上代码。
adaptee = $adaptee;
}
//委派调用Adaptee的sampleMethod1方法
public function doMouthOpen()
{
$this->adaptee->openMouth();
}
public function doMouthClose()
{
$this->adaptee->closeMouth();
}
}
//类适配器角色:绿枣遥控公司
class GreenAdapter implements GreenTarget
{
private $adaptee;
function __construct(Toy $adaptee)
{
$this->adaptee = $adaptee;
}
//委派调用Adaptee：GreenTarget的operateMouth方法
public function operateMouth($type = 0)
{
if ($type) {
$this->adaptee->openMouth();
} else {
$this->adaptee->closeMouth();
}
}
}
class testDriver
{
public function run()
{
//实例化一只狗玩具
$adaptee_dog = new Dog();
echo "给狗套上红枣适配器\n";
$adapter_red = new RedAdapter($adaptee_dog);
//张嘴
$adapter_red->doMouthOpen();
//闭嘴
$adapter_red->doMouthClose();
echo "给狗套上绿枣适配器\n";
$adapter_green = new GreenAdapter($adaptee_dog);
//张嘴
$adapter_green->operateMouth(1);
//闭嘴
$adapter_green->operateMouth(0);
}
}
$test = new testDriver();
$test->run();更加烦躁
最后的结果就是，Toy类及其子类在不改变自身的情况下，通过适配器实现了不同的接口。
最后的总结
将一个类的接口转换成客户希望的另外一个接口,使用原本不兼容的而不能在一起工作的那些类可以在一起工作.
适配器模式核心思想：把对某些相似的类的操作转化为一个统一的“接口”(这里是比喻的说话)--适配器，或者比喻为一个“界面”，统一或屏蔽了那些类的细节。适配器模式还构造了一种“机制”，使“适配”的类可以很容易的增减，而不用修改与适配器交互的代码，符合“减少代码间耦合”的设计原则。
