好久没更新了，今天给大家更新一篇设计模式文章——适配器模式。如果你做过Android开发，那么你肯定对适配这个词很熟悉。适配的作用就是让我们的应用程序能适用于各大主流的Android手机平台。
适配，通俗地讲，就是将极具个性的人，加以合适的引导，让其发挥其最大的作用。这个极具个性的人，就是Adaptee（适配者），发挥作用就是Target（我们的目标），引导的这个人就是Adapter（适配器）。
举个简单的例子，想必这个段子大家之前都听过。段子这么说，12306的老板说，我们开发个网上售票的系统。老板下达命令给经理，经理把这个项目外包给高校的老师来做，高校的老师说，同学们给你们个毕设题目，限什么时候完成。（当然这仅仅是个段子，实际肯定不是这样的，12306真的已经很不错了，为了引起大家学习的兴趣，就当哗众取宠吧）。
我们简化下中间的层层关系，留下3个主要的角色，一个是老板，一个是经理，一个是学生。老板提出需求Target，老板不懂技术，所以实际干活的是学生Adaptee。
你可能会问了，为什么需要经理呢？
为什么不是老板直接和学生交流呢？当然不行，倒不是因为面子的问题，而是老板还有更重要的事情做，做整体的调度以及重大策略的决断，这个项目只是其中的一个决定而已，所以是不方便也没时间与学生直接沟通的，所以经理Adapter出现了，负责向上级汇报，以及与学生沟通。
那么用关系图如何描述呢？
由图可以看出，在Manager里面，我们实际调用的是Student的codingBuild()方法。那么如何用伪代码实现呢？
class Manager implements Boss extends Student{
@Override
public void buildWebSystem(){
codingBuild();
}
}
上面就是类适配器的简单写法，那么这么写有没有什么问题呢？
我们默认Target是Interface，万一Target类是个抽象类呢？我们知道Java是不支持多继承的，所以这么写肯定是有问题的。
如果Adaptee是final类型，那么就不能被继承。
我们知道尽量少用继承，多用组合。
那么有没有其他写法呢？所以对象适配器出现了。
class Manager implements Boss{
private Student stu；//适配者
public void setStudent(Student stu){
this.stu = stu;
}
@Override
public void buildWebSystem(){
tu.codingBuild();
}
}
我们可以看到，在适配器（Adapter）类中持有一个适配者（Adaptee）对象，在适配器的方法中调用该适配者的方法。
那么这样写有什么好处呢？
我们不用关心具体系统是如何实现的，所以对Adapter是透明的，将任务委托给Adaptee来实现，只要知道达到我们的任务要求就可以了，也不用改动现有的组织结构。
假如我们对该适配者所做的工作不满意，我们可以随时更换其他的适配者，而不用改动太多代码。
那么适配者模式的使用场景呢？
- 不想了解具体的业务实现或者无法了解到具体的业务实现时可以使用该模式。因为对调用者是透明的，我只需要制定规范，将具体实现“外包”给Adaptee来做；
- 如果需求更换较为频繁，需要将具体的实现灵活性提高的时候可以使用该模式。说得专业点就是更换算法更为方便；
- 如果想使得具体实现（Adaptee）的复用性更好，可以使用该模式。
适配者模式基本上说完了，是不是很简单？
稍微拓展一下，说一下双向适配器。双向适配器（Adapter）同时持有Target和Adaptee。简单的示例代码说下。
class Manager implements Boss extends Student{
private Boss boss; // Target
private Student stu; //Adaptee
public setBoss(Boss boss){
this.boss = boss;
}
public setStudent(Student stu){
this.stu = stu;
}
@Override
public void buildWebSystem(){
tu.codingBuild();
}
public void codingBuild(){
boss.buildWebSystem();
}
}
这种实现我见得不多，作为了解。
还有一种缺省适配器有必要说一下。假设我们现在有接口类A里面有很多方法。
interface A{
public void methodA();
public void methodB();
public void methodC();
...
}
我们现在有个类B要用到A接口里面的方法methodA(),怎么办呢？很简单啊，直接让B实现接口A不行吗？当然行。但是我们就必须为了这个methodB()而实现methodA()、methodC()...如果A里面的方法数目很多，那么将在我们的B类中出现大量的无用代码，因为除了methodA()都是空实现。有没有比较好的实现方式呢？
//适配者接口
public interface A {
public void methodA();
public void methodB();
public void methodC();
public void methodD();
}
//缺省适配器类
public abstract class B implements A {
@Override
public void methodA() {
}
@Override
public void methodB() {
}
@Override
public void methodC() {
}
@Override
public void methodD() {
}
}
//具体业务类
public class C extends B {
@Override
public void methodA() {
//TODO
}
}
由代码可以看出，我们在中间引入了一个抽象类B，用于对接口A中的所有方法空实现。最后在C中具体实现我们想要的目标方法。
这么做的好处呢？
虽然也出现了没用的代码，但是我们这么做只需要让这些代码出现一次，而不是没一个新的类中都要空实现一遍。
那么为什么B要是abstract的呢？
我是这么理解的，因为B中所有的方法都是空实现，所以这个类没实际意义，真正起作用的是具体的实现类C，这里面具体实现我们想要的功能。为了避免大家实例化这个没实际用处的类，所以声明为abstract类型。每个类都有自己的职责以及名字，A（适配者接口），B（缺省适配器类），C(具体业务类)。
好了，适配器模式基本上说完了，希望可以给新手一点点帮助。
