适配器模式:将一个类的接口转换成客户希望的另外一个接口,Adapter模式使得原本由于接口不兼容而不能一起工作的哪些类可以一起工作。
适配器模式有三种不同的类别,分别是:类适配器模式、对象的适配器模式、接口的适配器模式。
- 类适配器模式
我们直接看代码吧:
适配前接口
public interface Voltage220 {
public int out220();
}
适配后接口
public interface Voltage5 {
public int put5();
}
适配前实现:
public class VoltageImpl220 implements Voltage220{
@Override
public int out220() {
return 220;
}
}
类适配器
public class Adapter extends VoltageImpl220 implements Voltage5 {
@Override
public int put5() {
int v = out220();
System.out.println("现在电压="+v);
System.out.println("i'm adapter ,I do something");
v = v/44;
System.out.println("现在电压="+v);
return v;
}
}
适配器使用类
public class Phone {
public void recharge(Voltage5 voltage5){
if(voltage5.put5()==5)
System.out.println("可以充电");
else
System.out.println("不能冲");
}
}
这种类适配器写法需要继承适配前类,这不易于扩展,有一定局限性。
- 对象适配器模式
基本思路和类的适配器模式相同,只是将Adapter类作修改,这次不继承src类,而是持有src类的实例,以解决兼容性的问题。
(根据“合成复用原则”,在系统中尽量使用关联关系来替代继承关系,因此大部分结构型模式都是对象结构型模式。)
适配原型与适配后没有改变只改变了适配器的写法
public class Adapter2 implements Voltage5{
private Voltage220 v220;
public Adapter2(Voltage220 v220){
this.v220 = v220;
}
@Override
public int put5() {
int v = 0;
if(null != v220){
v = v220.out220();
System.out.println("现在电压="+v);
System.out.println("i'm adapter ,I do something");
v = v/44;
System.out.println("现在电压="+v);
}
return v;
}
}
对象适配器和类适配器其实算是同一种思想,只不过实现方式不同。
根据合成复用原则,组合大于继承,
所以它解决了类适配器必须继承适配前类的局限性问题,也不再强求适配后必须是接口。
同样的它使用成本更低,更灵活。
- 接口适配器模式
当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法),那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求,它适用于一个接口不想使用其所有的方法的情况。
我们看一下代码:
public interface Person {
public void walk();
public void run();
public void sleep();
public void eat();
}
public abstract class AdapterPerson implements Person {
@Override
public void walk() {
}
@Override
public void run() {
}
@Override
public void sleep() {
}
@Override
public void eat() {
}
}
public class CandyParty {
public void eatCandy(){
Person xiaohong = new AdapterPerson() {
@Override
public void eat(){
System.out.println("eat candy");
}
};
xiaohong.eat();
}
}
这样是不是我们只需要实现我们所需要的吃接口就ok了?这样简单明亮。
优点:
1. 可以让任何两个没有关联的类一起运行。
2. 提高了类的复用。
3. 增加了类的透明度。
4. 灵活性好。
这个模式真的太好理解了就不做太多的解释了。