软件体系结构--适配器模式

蔚落 2022-02-01 02:31 242阅读 0赞

### 文章目录 ###

*  概念
 *  例子
 *  总结
 *   *  优点
     *  缺点

# 概念 #

适配器模式将一个类的接口，转换成客户期望的另一个接口。

就像生活中常见的转接头，转接头可以帮助我们将一种接口转换为另一种完全不同的接口。**那么这个转接头就是适配器。**

适配器分为两种：

*  类适配器
 *  对象适配器

**类适配器类图：**

![image][]

可以看出，类适配器模式需要语言支持多继承，而在不支持多继承的语言中，则需要使用对象适配器。

**对象适配器类图：**

![image][image 1]

类适配器中的适配器是继承自`Target`和`Adaptee`的。而对象适配器中的适配器与`Adaptee`之间是依赖关系，同时也是`Target`的实现类。

# 例子 #

最近因为换了台新的MacBook Air的原因，导致我不得不去买一个USB Type-c转USB-A的转换器。这个转换器就体现了适配器模式的思想。

**USB Type-c接口：**

public interface Type-C{
        
        public void transferData();
        public void charge();
    }

**USB A类：**

public class USB-A{
        
        public void transferData-A(){
        
            System.out.println("用USB A接口传输数据");
        }
        public void charge-A(){
        
            System.out.println("用USB A接口充电");
        }
    }

**USB Type-c USB-A转换器类：**

public class Adapter implements Type-c{
        
        private USB-A usb-a;
        public Adapter(USB-A usb-a){
        
            this.usb-a = usb-a;
        }
        @Override
        public void transferData(){
        
            System.out.println("在转换器中使用USB-A的传输数据方法")
            this.usb-a.transferData-A();
        }
        
        @Override
        public void charge(){
        
            System.out.println("在转换器中使用USB-A的充电方法")
            this.usb-a.charge();
        }
    }

# 总结 #

可能会有人觉得“为什么不直接去修改接口或类让他们的api一样？”

也许在一个非常非常小的项目里这样做不会出现什么问题（但依旧繁琐）。但是在一个大的项目里面，一个接口很可能已经被多处使用，一旦修改则是牵一发而动全身。

还有可能是引入了第三方的jar包，那在这种无法解除到源码的情况下想要使其符合自己的接口定义，除了适配器别无二法。

## 优点 ##

可以让两个不相干的类一起运行，无需修改旧代码，灵活性好

## 缺点 ##

适配器模式用多了会使整个系统变得很复杂，因为你调用的是适配器，却不知道适配器内部做了多少转换操作，所以在能用别的办法解决问题时，尽量少用适配器模式。

[image]: /images/20220201/387890e6b73f4ab89c071cc6bcedd728.png
[image 1]: /images/20220201/4f17de46a1694565a38d294a65a27fa0.png