。

想象这样一个场景#xff0c;原项目中接口返回的数据是XML格式的数据#xff0c;但现在来了一个新客户#xff0c;它期望接口返回的数据类型为json格式的。

想要…总目录

在实际的开发过程中由于需求的变化和扩展我们的代码也需要做相应的扩展。

想象这样一个场景原项目中接口返回的数据是XML格式的数据但现在来了一个新客户它期望接口返回的数据类型为json格式的。

想要实现要么就是改原有接口但这样就违反了开闭原则容易出现未知bug影响到老客户的正常使用。

而如果写一个适配器类也就是转换类第三方类将原本返回的XML格式数据转换成json格式数据而具体数据是怎么来的则直接用原有接口方法就可以这就是适配器模式。

基本介绍

定义将一个类的接口转换成客户端所期望的另一个接口使得原本由于接口不兼容而无法协同工作的类能够一起工作。

适配器模式有类的适配器模式和对象的适配器模式两种形式适配器模式Apapter

Pattern是一种结构型设计模式用来解决现有对象与客户端期待接口不一致的问题适配器模式中的角色

目标角色Target描述了其他类与客户端代码合作时必须遵循的协议。

客户角色Client与符合Target接口的对象协同。

被适配服务类功能类Adaptee)定义一个已经存在并已经使用的接口这个接口需要适配。

客户端与其接口不兼容

适配器模式的核心。

适配器接受客户端通过适配器接口发起的调用同时根据其内在逻辑调用对应服务类。

客户端代码只需通过接口与适配器交互即可

现实生活中空调插头一般都是三头的但如果家里只有两孔插座那必然是插不进去的。

而如果提供一个拥有三孔插座和两头插头的转换器的话那空调可以先插在这个转换器上然后这个转换器再插在插座上就可以了。

本质并没有变只是将二孔插座包装了一下向外界提供了一个三孔插座的外观以供客户使用。

适配的本质就是转换将不满足使用条件的东西通过第三方类进行加工处理成可使用的东西。

使用场景

系统需要复用现有类但是接口又与复用环境要求不一致的情况。

旧系统与新系统的兼容可以使新系统能够无缝地与老旧系统进行通信。

第三方组件的集成适配器可以将第三方组件的接口转换为符合我们系统需求的接口形式从而能够顺利地集成到我们的系统中。

多个类库之间的互操作适配器模式可以起到桥梁的作用。

实现方式

sql){Console.WriteLine($SqlServerHelper执行了【操作】sql:{sql});}public

void

sql){Console.WriteLine($SqlServerHelper执行了【查询】sql:{sql});}}//

实现public

sql){Console.WriteLine($MySqlHelper执行了【操作】sql:{sql});}public

void

sql){Console.WriteLine($MySqlHelper执行了【查询】sql:{sql});}}//业务扩展了关系型数据库已经不满足于现在的业务了//需要给系统增加缓存用到了非关系型数据库//非关系数据库辅助类

【被适配者】public

NoSqlHelper{//非关系数据库【特有的】操作数据方法public

void

str){Console.WriteLine($NoSqlHelper执行了【操作】:{str});}//非关系数据库【特有的】查询数据方法public

void

str){Console.WriteLine($NoSqlHelper执行了【查询】:{str});}}//适配器类public

class

IDbHelper{//实际上调用非关系型数据库的数据操作方法public

void

sql){base.ExecNoSqlDML(sql);}public

void

args){//客户端可以通过适配器来使用IDbHelper这个数据库辅助类//因为通过NoSqlHelperAdapter

dbHelper

NoSqlHelperAdapter();dbHelper.ExecDML(...);Console.ReadLine();}从实例中可以看出类适配器主要是用继承来实现的但如果有很多个类进行适配这个方式就不支持了。

对象适配器

sql){Console.WriteLine($SqlServerHelper执行了【操作】sql:{sql});}public

void

sql){Console.WriteLine($SqlServerHelper执行了【查询】sql:{sql});}}//

实现public

sql){Console.WriteLine($MySqlHelper执行了【操作】sql:{sql});}public

void

sql){Console.WriteLine($MySqlHelper执行了【查询】sql:{sql});}}//业务扩展了关系型数据库已经不满足于现在的业务了//需要给系统增加缓存用到了非关系型数据库//非关系数据库辅助类public

class

str){Console.WriteLine($NoSqlHelper执行了【操作】:{str});}//非关系数据库查询数据public

void

str){Console.WriteLine($NoSqlHelper执行了【查询】:{str});}}仅仅是适配类的代码发生改变

//适配器public

sql){//通过实例调用相关数据操作的方法noSqlHelper.ExecNoSqlDML(sql);}public

void

sql){noSqlHelper.ExecNoSqlDQL(sql);}}从实例中可以看出对象适配器其实就是在适配器类中创建了一个被适配者的实例从而将两者联系在一起。

这种方式采用

从两个案例上知道适配器模式并不是项目一开始就会用到的而是随着需求的变更和扩展我们不得已才开发一个适配器类将新增的功能通过适配器类

“包一层”

的方式转换为我们原有对外提供的接口使得我们可以在不修改原有代码的基础上来复用现有类很好地符合

“开闭原则”

“开闭原则”可以重新定义Adaptee(被适配的类)的部分行为因为在类适配器模式中Adapter是Adaptee的子类仅仅引入一个对象并不需要额外的字段来引用Adaptee实例这个即是优点也是缺点。

使得重定义Adaptee(被适配的类)的行为较困难这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。

参考资料