适配器模式
一：生活中一些实例？
简单说现在家庭中使用的电器一般要求电压是220V的，但是有的电器使用要求的电压是110V，怎么办呢？我们直接在110V电压电器上直接安装一个变压器这样不就行了吗？这样我们不就可以使用110V电压的电器了吗？
相信很多人都知道恒大足球队吧，他们队里有一些外援，他们语言不同，他们是怎么交流了，按照我们想，让对内的球员都会说中文不就好了。这样对内的交流问题不就解决了。
二：上面实现功能中会出现什么问题呢？
如果使用电器中出现其他电压电器，或者有很多110V电压的电器，我们就需要每次都添加一个变压器，给没有这个转换电压功能，每一次都需要添加一次方法。这样做的，每一次都需要我们去添加方法，修改里面原代码，这样做违反开闭原则，那么我们要如何做呢？我们可以在外面是先一个接口，然后将转化方法放在里面，我们需要时候就去调用，这样不是会很方便。
同样的如果队里球员都学习中文，第一不说中文学期很难，第二学习也很占用时间，这样会影响球员的休息还有训练。但是如果我们给球员带一个翻译器呢？是不是这样问题就解决了呢？
三：再设计模式中：适配器模式
在适配器模式中如何解决电压问题呢？
创建接口:
定义变压器类：
定义改变适配器的类:
定义变压器地输出110V:
定义输出220V电压类:
这样我们就在原有类的基础上，实现调用，也解决每次都需要添加麻烦。也让两个不能在一起工作在一起工作。
四：适配器模式定义：
适配器模式（Adapter）：就是把一个类的接口转换成客户所期待的另一种接口。Adapter使得原本由于接口不兼容而不能在一起工作的那些类可以在一起工作。
一) 适配器模式的结构
适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。
类适配器通过继承，是静态的定义方式。
对象适配器通过代理，是动态组合的方式。
类适配器模式
类适配器模式把适配的类API转换成目标类的API
从图中可以看出Adaptee中没有sampleOperation2()方法，而客户端则期待这个方法。为了使客户端能够使用这个Apaptee类，所以提供一个中间环节，即类Adapter，也就是这个类把Adaptee与Target类衔接起来。Adapter与Apaptee是继承关系，这就决定是类适配器模式。
模式中角色：
目标(Target) 角色：目标角色，期待得到的接口。
源(Adapee)角色: 适配者角色，现在需要适配的接口。
适配器(Adapter)角色：适配器角色，适配器类是本模式核心。适配器把源接口转换成目标接口。显然这一角色不可能是接口，而必须是具体类。
代码样例：
目标角色：
源(Adapee)角色：
适配器角色Adapter：
对象适配器模式
与类的适配器模式一样，对像的适配器模式把被适配器的类的API转换成目标类的API，与类适配器不同的是，对象适配器模式不使用继承关系连接到Adaptee类，使用了委派关系连接到了Adaptee类。
从图中可以看出Adaptee类中没有sampleOperation2()方法，客户端是期待这个方法的。为了使客户端能够使用Adaptee类，我们需要提供一个包装(Wrapper类)Adapter。这个包装类包装一个Adatee的实例，从而能使的包装类能把Adaptee的API与Target类的API衔接起来。Adater与Adaptee是委派关系，这就决定是对象适配器模式
目标角色：
源角色：
适配器角色：
我们了解适配器模式，那么我们看看实际项目中我们应当怎么使用呢？
例如公司购买了一个验证客户信息的离架产品类InfoValidation，但是卖方没有提供源码。此类只提供用于检查客户输入的信息，包含验证姓名、地址、电话区号、手机号等功能。现在公司需要增加一个验证社会安全号(SSN)的功能，这里我们不就可以使用类适配器来做吗？这里我们首先想一下类适配器结构，然后来构建这里所要实现结构。
结构部分：
下面是我们代码实现部分：
根据我们以上结构来一步一步实现我们代码部分：这样就会非常简单
首先编写接口部分：
public interface CusInfoValidator {
public abstract boolean isValidName(String name);
public abstract boolean isValidAddress(String address);
public abstract boolean isValidZipCode(String zipCode);
public abstract boolean isValidCellPhoneNum(String phoneNum);
public abstract boolean isValidSSNNum(String SSNNum);
}
是不是跟我们结构一样的
接下来我们再来编写所继承类InfoValidation类(被适配器类)
Class InfoValidation {
public abstract boolean isValidName(String name) {
boolean isValid=true;
String ns = name.trim();
String nStr = ns.replaceAll("\\b\\s{1,}\\b", "");
int len = nStr.length();
System.out.println("******Length = " + len);
if(len != 0 ){
for(int m=0; m<len; m++){
if(Character.isDigit(nStr.charAt(m))==true)
isValid=false;
}
return isValid;
}
else{
return false;
}
}
public abstract boolean isValidAddress(String address){代码省略}
public abstract boolean isValidZipCode(String zipCode){代码省略}
public abstract boolean isValidCellPhoneNum(String phoneNum){代码省略}
}
实现我们适配器代码：
class InformationAdapter extends InfoValidation implements CusInfoValidator{
public boolean isValidSSNNum(String SSNNum){
boolean isValid=true;
String ns = SSNNum.trim();
String nStr = ns.replaceAll("\\s{1,}", "");
int len = nStr.length();
if ( (nStr.charAt(3) == '-') && (nStr.charAt(6) == '-') && (len==11) ) {
for(int m=0; m<len; m++){
if( (m != 3) && (m !=6) && ( Character.isDigit(nStr.charAt(m))==false) ){
isValid=false;
}
}
return isValid;
}
else{
return false;
}
}
}
这样我们就在原有功能上添加一个社会安全号SSN验证功能。通过这个实例，可能就会有会问：“适配器模式是不是就是给源角色增加新的方法！”，这样说也对但是不全面。
在适配器模式定义中主要讲的是让接口变换成客户端所期待一种接口，也就是说‘适配器模式’可以用于增加新的方法，但主要还是转换接口。例如下面一般是我们人物信息例子：
上面结构途中在Person类中是没有getDepartment() 方法，在适配器改变Person类构造函数的参数，添加了demartment参数，适配器是改变是接口。我们这个设计目的不是增加方法，而是改变接口。
五： 我们又该怎么权衡类配置器和对象适配器呢，它们又有什么特点呢？
在上面我们写到类适配器是适用对象继承的方式，是静态的方式，而对象适配使用时对象组合方式，是动态组合方式。
对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不可能再去处理 Adaptee的子类了。
对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。
对于类适配器，适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现方法。
对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。
对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee。
对于对象适配器，需要额外的引用来间接得到Adaptee。
建议尽量使用对象适配器的实现方式，多用合成/聚合、少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合的才是最好的。
六：那么又有哪些适配器模式的又有哪些优缺点呢？
优点：
1.将目标类和适配者类解耦，通过一入一个适配器类来重用现有的适配者类，而无需要修改原有代码。
2.增加了类的透明度和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性。
3.灵活性和扩展性都非常好，通过使用配置文件可以很方便的更换适配器，也可以在不修改原有代码基础上增加新的适配器类，完全符合“开闭原则”。
缺点：
过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
七：我们又该怎样使用适配器呢？
使用场景：
1).系统中需要使用现有类，而这个类接口不符合系统的需要，也就是不兼容
2).想要建立一个可重复使用的类，用于关联彼此没有太大联系的一些类
3).需要一个统一的输出接口，而输入端类型不确定
八：适配器模式总结
适配器模式可以重用一个现有的类，满足客户需求，将客户端的调用转化为现有方法调用。
类适配器：客户端的需求通过接口表达出来，可以创建一个实现该接口的适配类，适配类同时还要继承现有类。
对象适配器：客户端没有指定接口，创建一个新的适配器类，实现继承客户端类，在该类中维护一个现有的类实例对象作为成员变量。
