Java设计模式——Adapter 适配器模式(1)

写在前面：在四人帮提出的23种设计模式中，每一种设计模式实际上都是为了解决一个编程语言没有实现却又需要的特性。将这23种设计模式进行归类，分为：接口型、责任型、构造型、操作型、扩展型。设计模式中有许多已经可以用开源框架替代，但熟悉每一种设计模式毕竟是每个架构师必修的功课，就像每个化学家都还是需要背诵元素周期表一样。

接口型之一——Adapter适配器

适配器模式简单的说就是为了解决两个既有系统之间的调用问题，看一下实物适配器 就是解决这样一个难题的。举个例子来说，当你正在开发一套网上购物商城系统时，你原本打算采用Soft银行的支付接口进行支付，双方都约定了接口名称与方法进行开发

interface Payment {
       public boolean pay();
}

你调用的方法类似于

class YourClient {
       public void buy(){
       ....
       Payment yp = ... 
       yp.pay();
       ....
       }
} 

你的系统已经开发完成了，就等着Soft银行的pay()方法的实现了，突然Soft银行因债务问题而破产，于是你被迫更换你的支付银行Hard银行，而Hard银行已经有一套完整的支付接口实现了，只不过方法的名字不太一样。

class HardBank {
     public boolean zhifu(){
           ...
     }
}

看来解决方法很简单了，只需要让Hard银行将自己的方法修改成：

class HardBank implements Payment {
      public boolean zhifu(){
           ...
      }
      
      public void pay() {
           this.zhifu();
      }
}

但是要修改Hard银行的代码令对方很不满，对方认为如果每个购物商城都提出这种要求，那他们的代码将会变成

class HardBank implements Payment,Bill,Fuqian... {
      public boolean zhifu(){
           ...
      }
      
      public void pay() {
           this.zhifu();
      }
      
      public void bill() {
           this.zhifu();
      }
      
      public void fuqian() {
           this.zhifu();
      }
      
      .... 
}

于是只能修改你网上商城的代码，一种方法，你可以搜索系统中所有的Payment，调用的pay()方法全部改成zhifu()，又或者你可以使用一个适配器来弥补双方方法的差异

class MyPaymentAdapter extends HardBank implements Payment {
      public boolean pay() {
           super.zhifu();
      }
}

 回顾一下最后的解决方案

 以上就是一个简单的类适配器