有大半个月都没有写随笔了，主要是大四升学来一大堆乱七八糟的事情，找工作碰壁。主要也怪自己实力不济，更主要的是缺乏亮眼实战经验，很难引起HR的兴趣。所以在这里还是做个小广告，希望有哪个能赐一份儿工作，实习也无所谓，最不济实习不给工资也行嘛（我被打击的已经完全没有底线了）。地点随便，但目前我只能在成都读完这剩下的一年书，反正写代码哪儿都行嘛。
说来惭愧，我总是觉得自己“懂得很多大道理，就是过不好这一生”。这些博客分享也不管有没有人看，总是要写出自己现有的认知，更多的是希望得到前辈的指导。
回归主题，前面分享完基本的三种设计模式，今天分享另一种我们感觉不常用到，但这到需要的时候大呼方便的模式--适配器模式。
在这个有没有对象都要高呼“面向对象”的年代，掌握面向对象会给我们带来意想不到的方便。学编程的小伙伴从开始能写几行代码实现简单功能到后来懂得将一些重复的操作组合起来形成一个“函数”，再到后来将“函数”和属性组合起来形成一个“类”。一步步走来，我们在考虑着机器运行代码效率的提高的同时也在考虑减轻程序员的工作量。 那么我们今天讲到的适配器模型更着重考虑的是什么呢？是程序员工作量。
什么时候会用到适配器模式？
其实最简单的例子是当我们引用一个第三方类库。这个类库随着版本的改变，它提供的API也可能会改变。如果很不幸的是，你的应用里引用的某个API已经发生改变的时候，除了在心中默默地骂“wocao”之外，你还得去硬着头皮去改大量的代码。
难道真的一定要如此吗？按照套路来说，我会回答“不是的”。我们有适配器模式啊~~
当接口发生改变时，适配器模式就派上了用场。
举个栗子
如果通过上面的简单描述，你都能懂，那在下只能佩服你的领悟能力超群了。一般人一定还是不知所云。为了方便理解，我引用一位博友的例子。原文地址。
一开始的和谐
黑枣玩具公司专门生产玩具，生产的玩具不限于狗、猫、狮子，鱼等动物。每个玩具都可以进行“张嘴”与“闭嘴”操作，分别调用了openMouth与closeMouth方法。
在这个时候，我们很容易想到可以第一定义一个抽象类Toy,甚至是接口Toy,这些问题不大，其他的类去继承父类，实现父类的方法。一片和谐，信心向荣。
平衡的破坏
为了扩大业务，现在黑枣玩具公司与红枣遥控公司合作，红枣遥控公司可以使用遥控设备对动物进行嘴巴控制。不过红枣遥控公司的遥控设备是调用的动物的doMouthOpen及doMouthClose方法。黑枣玩具公司的程序员现在必须要做的是对Toy系列类进行升级改造，使Toy能调用doMouthOpen及doMouthClose方法。
考虑实现的方法时，我们很直接地想到，你需要的话我再在我的父类子类里给你添加这么两个方法就好啦。当你一次又一次在父类子类里面重复添加着这两个方法的时候，总会想着如此重复的工作，难道不能解决么？当有数百个子类的时候，程序员会改疯的。程序员往往比的是谁在不影响效率的时候更会“偷懒”。这样做下去程序员会觉得自己很傻。(其实我经常当这样的傻子)
abstractclassToy
{publicabstractfunctionopenMouth();publicabstractfunctioncloseMouth();//为红枣遥控公司控制接口增加doMouthOpen方法publicabstractfunctiondoMouthOpen();//为红枣遥控公司控制接口增加doMouthClose方法publicabstractfunctiondoMouthClose();
}classDogextendsToy
{publicfunctionopenMouth()
{echo"Dog open Mouth\n";
}publicfunctioncloseMouth()
{echo"Dog open Mouth\n";
}//增加的方法publicfunctiondoMouthOpen()
{$this->doMouthOpen();
}//增加的方法publicfunctiondoMouthClose()
{$this->closeMouth();
}
}classCatextendsToy
{publicfunctionopenMouth()
{echo"Cat open Mouth\n";
}publicfunctioncloseMouth()
{echo"Cat open Mouth\n";
}//增加的方法publicfunctiondoMouthOpen()
{$this->doMouthOpen();
}//增加的方法publicfunctiondoMouthClose()
{$this->closeMouth();
}
}
更加烦躁
程序员刚刚码完代码，喝了口水，突然间另一个消息传来。
黑枣玩具公司也要与绿枣遥控公司合作，因为绿枣遥控公司遥控设备更便宜稳定。不过绿枣遥控公司的遥控设备是调用的动物的operMouth($type)方法来实现嘴巴控制。如果$type为0则“闭嘴”，反之张嘴。
这下好了，程序员又得对Toy及其子类进行升级，使Toy能调用operMouth()方法。搁谁都不淡定了。
abstractclassToy
{publicabstractfunctionopenMouth();publicabstractfunctioncloseMouth();publicabstractfunctiondoMouthOpen();publicabstractfunctiondoMouthClose();//为绿枣遥控公司控制接口增加doMouthClose方法publicabstractfunctionOperateMouth($type= 0);
}classDogextendsToy
{publicfunctionopenMouth()
{echo"Dog open Mouth\n";
}publicfunctioncloseMouth()
{echo"Dog open Mouth\n";
}publicfunctiondoMouthOpen()
{$this->doMouthOpen();
}publicfunctiondoMouthClose()
{$this->closeMouth();
}publicfunctionoperateMouth($type= 0)
{if($type== 0) {$this->closeMouth();
}else{$this->operateMouth();
}
}
}classCatextendsToy
{publicfunctionopenMouth()
{echo"Cat open Mouth\n";
}publicfunctioncloseMouth()
{echo"Cat open Mouth\n";
}publicfunctiondoMouthOpen()
{$this->doMouthOpen();
}publicfunctiondoMouthClose()
{$this->closeMouth();
}publicfunctionoperateMouth($type= 0)
{if($type== 0) {$this->closeMouth();
}else{$this->operateMouth();
}
}
}
在这个时候，程序员必须要动脑子想办法了，就算自己勤快，万一哪天紫枣青枣黄枣山枣这些遥控公司全来的时候，忽略自己不断增多的工作量不说，这个Toy类可是越来越大，总有一天程序员不崩溃，系统也会崩溃。
问题在出在哪里呢？
像上面那样编写代码，代码实现违反了“开-闭”原则，一个软件实体应当对扩展开放，对修改关闭。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。也就是说每个尸体都是一个小王国，你让我参与你的事情这个可以，但你不能修改我的内部，除非我的内部代码确实可以优化。
在这种想法下，我们懂得了如何去用继承，如何利用多态，甚至如何实现“高内聚，低耦合”。
回到这个问题，我们现在面临这么一个问题，新的接口方法我要实现，旧的接口（Toy抽象类）也不能动，那么总得有个解决方法吧。那就是引入一个新的类--我们本文的主角--适配器。 适配器要完成的功能很明确，引用现有接口的方法实现新的接口的方法。更像它名字描述的那样，你的接口不改的话，我就利用现有接口和你对接一下吧。
到此，解决方法已经呼之欲出了，下面贴上代码。
<?phpabstractclassToy
{publicabstractfunctionopenMouth();publicabstractfunctioncloseMouth();
}classDogextendsToy
{publicfunctionopenMouth()
{echo"Dog open Mouth\n";
}publicfunctioncloseMouth()
{echo"Dog close Mouth\n";
}
}classCatextendsToy
{publicfunctionopenMouth()
{echo"Cat open Mouth\n";
}publicfunctioncloseMouth()
{echo"Cat close Mouth\n";
}
}//目标角色:红枣遥控公司interfaceRedTarget
{publicfunctiondoMouthOpen();publicfunctiondoMouthClose();
}//目标角色:绿枣遥控公司及interfaceGreenTarget
{publicfunctionoperateMouth($type= 0);
}//类适配器角色:红枣遥控公司classRedAdapterimplementsRedTarget
{PRivate$adaptee;function__construct(Toy$adaptee)
{$this->adaptee =$adaptee;
}//委派调用Adaptee的sampleMethod1方法publicfunctiondoMouthOpen()
{$this->adaptee->openMouth();
}publicfunctiondoMouthClose()
{$this->adaptee->closeMouth();
}
}//类适配器角色:绿枣遥控公司classGreenAdapterimplementsGreenTarget
{private$adaptee;function__construct(Toy$adaptee)
{$this->adaptee =$adaptee;
}//委派调用Adaptee：GreenTarget的operateMouth方法publicfunctionoperateMouth($type= 0)
{if($type) {$this->adaptee->openMouth();
}else{$this->adaptee->closeMouth();
}
}
}classtestDriver
{publicfunctionrun()
{//实例化一只狗玩具$adaptee_dog=newDog();echo"给狗套上红枣适配器\n";$adapter_red=newRedAdapter($adaptee_dog);//张嘴$adapter_red->doMouthOpen();//闭嘴$adapter_red->doMouthClose();echo"给狗套上绿枣适配器\n";$adapter_green=newGreenAdapter($adaptee_dog);//张嘴$adapter_green->operateMouth(1);//闭嘴$adapter_green->operateMouth(0);
}
}$test=newtestDriver();$test->run();
最后的结果就是，Toy类及其子类在不改变自身的情况下，通过适配器实现了不同的接口。
最后总结
将一个类的接口转换成客户希望的另外一个接口,使用原本不兼容的而不能在一起工作的那些类可以在一起工作.
适配器模式核心思想：把对某些相似的类的操作转化为一个统一的“接口”(这里是比喻的说话)--适配器，或者比喻为一个“界面”，统一或屏蔽了那些类的细节。适配器模式还构造了一种“机制”，使“适配”的类可以很容易的增减，而不用修改与适配器交互的代码，符合“减少代码间耦合”的设计原则。
以上
系列文章：
php模式设计之 单例模式
php模式设计之 工厂模式
php模式设计之 注册树模式
php模式设计之 适配器模式
php模式设计之 观察者模式