生活例子
泰国插座用的是两孔的(欧标), 我们国内的是矩形的, 没办法使用, 这个时候就可以买一个电源转换器(适配器) 就可以了
适配器模式基本介绍
- 适配器模式将某个类的接口转化成客户端期望的另一个接口表示, 主要的目的是兼容性, 让原本因接口不匹配不能一起工作的两个类可以协同工作, 其别名为包装器(Wrapper)
- 适配器模式属于结构型模式
- 主要分为三大类
- 类适配器
- 对象适配器
- 接口适配器
工作原理
- 适配器模式: 将一个类的接口转化成另一个接口, 让原本接口不兼容的类可以兼容
- 从用户的角度看不到被适配者, 是解耦的
- 用户调用适配器转化出来的目标接口方法, 适配器再调用被适配者的相关接口方法
- 用户收到反馈结果, 感觉只是和目标接口交互
我这个应该画的很容易理解了吧
类适配器模式
介绍
基本介绍 :Adapter 类 通过继承src类 实现dist类接口 完成 src -> dist 的适配
应用实例
需求
以生活中的例子来讲解适配器, 充电器本身相当于Adapter, 220V交流电相当于src, 我们的目标是适配为5V的交流电
类图
代码
代码语言:javascript复制package com.dance.design.designmodel.buildmodel.adapter;
public class Client {
public static void main(String[] args) {
Phone phone = new Phone();
phone.input5V(new VoltageAdapter().output5V());
}
}
/**
* 提供220V交流电
*/
class Voltage220V {
public Integer output220V(){
return 220;
}
}
/**
* 输出5V交流电
*/
interface Voltage5V {
Integer output5V();
}
/**
* 电压适配器
*/
class VoltageAdapter extends Voltage220V implements Voltage5V{
@Override
public Integer output5V() {
Integer voltage220V = output220V();
// 对220V电压逐渐减压
int i = voltage220V;
while (voltage220V > 5) {
voltage220V--;
}
// 返回5V电压
return voltage220V;
}
}
/**
* 手机
*/
class Phone{
public void input5V(Integer voltage){
if(voltage == 5){
System.out.println("电压OK, 正在充电");
} else if(voltage > 5){
System.out.println("电压过大, bong 沙卡拉卡");
} else {
System.out.println("电压过小, 滴.... 没电了");
}
}
}
注意事项和细节
- Java是单继承机制, 所以类适配器需要继承src类这一点算是一个缺点,应为这要求dist必须是接口,有一定的局限性
- 我觉得这其实违反了合成服用原则, 此处其实应该使用聚合,或者依赖会比较好,而不是继承, 通过依赖也能调用output220V接口
- src类的方法在Adapter中会暴露出来,也增加了使用的成本
- 所以说改成聚合或者依赖呀, 就不会暴露了
- 应为其继承了src类, 所以他可以根据需求重写src类的方法, 使得Adapter的灵活性增强了
- 我感觉使用依赖或者聚合应该也能扩展src类的方法
总结: 我感觉少用继承, 应该偏向于依赖或者聚合这种设计
对象适配器模式
介绍
- 基本思路和类的适配器模式相同, 只是将Adapter类修改了, 改成不是继承关系, 而是持有src类的实例, 以解决兼容性问题, 即: 持有src类, 实现dist接口完成src->dist的适配
- 额, 突然又感觉我5级了,我还在上面反复吐槽那个继承关系
- 根据 "合成复用原则", 在系统中尽量使用关联关系(聚合),来代替继承关系
- 对象适配器模式就是适配器模式常用的一种
应用实例
需求
采用类适配器模式的需求
类图
我感觉改成组合更加合适, 而不是聚合,因为如果是聚合的话,就需要外部知道这个220V的类, 而组合不需要, 尽量不要暴露过多的类, 而且这个类就是为了适配220V的电压的, 所以我认为应该是组合
代码
220V交流电改为单利模式
代码语言:javascript复制/**
* 提供220V交流电
*/
class Voltage220V {
private static final Voltage220V v = new Voltage220V();
private Voltage220V(){}
public Integer output220V(){
return 220;
}
public static Voltage220V getInstance(){
return v;
}
}
在适配器初始化的时候注入220V的单利
代码语言:javascript复制/**
* 电压适配器
*/
class VoltageAdapter implements Voltage5V{
private final Voltage220V voltage220VInstance;
/**
* 在初始化的时候 注入单利
*/
public VoltageAdapter(){
voltage220VInstance = Voltage220V.getInstance();
}
@Override
public Integer output5V() {
Integer voltage220V = voltage220VInstance.output220V();
// 对220V电压逐渐减压
int i = voltage220V;
while (voltage220V > 5) {
voltage220V--;
}
// 返回5V电压
return voltage220V;
}
}
注意事项和细节
- 对象适配器和类适配器其实算是同一种思想, 只不过实现方式不同
- 根据合成服用法则, 使用组合代替继承, 所以他解决了类适配器必须继承src的局限性问题, 也不再要求dist必须是接口了
- 使用成本更低,更灵活
接口适配器模式
介绍
- 一些书籍称为: 适配器模式或缺省适配器模式
- 核心思路: 当不需要全部实现接口提供的方法时, 可以设计一个抽象类实现接口, 并为该接口中每个方法提供一个默认实现(空方法), 那么该抽象类的子类可有选择的覆盖父类的某些方法来实现需求
- 其实在Java8之后接口就可以有默认的实现了, 这时这个抽象层其实是可以不要的
interface Inf{
default void output220V(){
}
default void output5V(){
}
static String getV(){
return "";
}
}
接口的默认实现需要使用default修饰 或者static修饰 一般如果需要实现去重写的话 一般使用default
- 适用于一个接口不想使用其所有方法的情况
应用案例
就还拿那个上面的需求来说吧
代码
代码语言:javascript复制package com.dance.design.designmodel.buildmodel.adapter;
public class Client2 {
public static void main(String[] args) {
ChargerAdapter charger = new ChargerAdapter() {
@Override
public int voltage5V() {
return 5;
}
};
System.out.println("用" charger.voltage5V() "V开始充电!!!");
}
}
interface Function {
int voltage220V();
int voltage110V();
int voltage30V();
int voltage5V();
}
abstract class ChargerAdapter implements Function {
public int voltage220V() {
return 0;
}
public int voltage110V() {
return 0;
}
public int voltage30V() {
return 0;
}
public int voltage5V() {
return 0;
}
}
其实就是加了一层
在Java8之后可以改进
代码语言:javascript复制package com.dance.design.designmodel.buildmodel.adapter;
public class Client2 {
public static void main(String[] args) {
Function function = new Function() {
@Override
public int voltage5V() {
return 5;
}
};
System.out.println("用" function.voltage5V() "V开始充电!!!");
}
}
interface Function {
default int voltage220V(){
return 0;
}
default int voltage110V(){
return 0;
}
default int voltage30V(){
return 0;
}
default int voltage5V(){
return 0;
}
}
接口提供了默认实现 ,这个时候就不需要抽象类了
源码剖析
SpringMvc中的应用
- SpringMvc中的HandlerAdapter, 就使用了适配器模式
- SpringMvc处理请求的流程回顾
- 使用HandlerAdapter的原因分析:
- 可以看到处理器的类型不同, 有多重实现方式,那么调用方式就是不确定的,如果需要 直接调用Controller方法, 需要调用的时候就不得不断的使用if else 来进行判断是哪一种子类然后执行. 那么如果后面要扩展Controller就得修改原来的代码, 这样违背了OCP原则
- 动手写SpringMvc通过适配器设计模式获取到对应的Controller的源码
适配器模式的注意事项和细节
- 三种命名方式, 是根据src是以怎样的形式给到Adapter(在Adapter里面的形式)来命名的
- 类适配器: 通过继承给到
- 对象适配器: 通过聚合,组合,依赖,(持有对象实例)给到
- 接口适配器: 通过接口给到
- Adapter模式最大的作用还是将原本不兼容的接口融合在一起工作
- 实际开发中, 实现起来不拘泥于我们讲解的三种经典模式