前言：
在软件设计中，已有的类与新接口之间不兼容的问题相当常见，同时，我们又不想为新的接口而重写现有的类。此时，就需要用到“适配器模式”。定义：将一个类的接口转换为客户希望的另一个接口，它使得原来由于兼容问题不能一起工作的那些类可以一起工作。（《设计模式》，Addison Wesley，1994）。通常，适配器模式有两种实现方式：类适配器，对象适配器 ，还有默认适配器模式。 百度百科中 关于适配器模式介绍的比较好，通俗易懂 百度百科适配器模式地址。
适配器模式的用途：
用电器做例子，笔记本电脑的插头一般都是三相的，即除了阳极、阴极外，还有一个地极。而有些地方的电源插座却只有两极，没有地极。电源插座与笔记本电脑的电源插头不匹配使得笔记本电脑无法使用。这时候一个三相到两相的转换器（适配器）就能解决此问题，而这正像是本模式所做的事情。适配器模式的结构适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。下面我们将通过一个 DEMO下载地址 项目使用swift 编写 。来说明这两种适配器模式，对比二者的优劣。 如下图所示项目的目录结构。
类适配器：
在整个项目中：
BusinessCardView ：是我们的Client 。它只需要name，lineColor，phoneNumber 这三种String ，Color，String 类型的变量。 但是我们有两个Model Normal 和 SpecialModel。 其中 SpecialModel的数据并不能直接满足Client的需求。是需要适配的对象
classSpecialModel:NSObject{
varname:String=""
/// 很明显 这个 colorString 和normalModel 中的 UIColor 属性是有区别的
varcolorString:String=""
//
varphoneNumber:String=""
}
为了使二者都能使用。 我们新增了 protocolBusinessCardAdapterProtocol 来对应Client 。
protocolBusinessCardAdapterProtocol {
funcname() ->String?
funclineColor() ->UIColor?
funcphoneNumber() ->String?
}
如图1-1 是ClassAdapter 模块。AdapterNormalModel 和 AdapterSpecialModel 分别继承自NormalModel 和 SpecialModel 并且执行了BusinessCardAdapterProtocol 协议。在执行协议方法过程中做出改变。
funclineColor() ->UIColor? {
varcolor:UIColor= UIColor.black
//
switchself.colorString {
case"red":color = UIColor.red
case"green":color = UIColor.green
default:
color = UIColor.black
}return color}
客户端调用代码：
private func classAdapterExample(){
letdata1:AdapterNormalModel=AdapterNormalModel()
data1.name="DeLongYang"
data1.lineColor=UIColor.red
data1.phoneNumber="139-1447-8563"
letcardView:BusinessCardView=BusinessCardView(frame:BUSINESS_FRAME)
cardView.center=self.view.center
cardView.loadData(data: data1)
self.view.addSubview(cardView)
}
private func classAdapterExampleTwo(){
letdata1:AdapterSpecialModel=AdapterSpecialModel()
data1.name="DeLongYang"
data1.colorString="green"
data1.phoneNumber="139-1447-8563"
letcardView:BusinessCardView=BusinessCardView(frame:BUSINESS_FRAME)
cardView.center=self.view.center
cardView.loadData(data: data1)
self.view.addSubview(cardView)
}
以上就是类适配器的思想。
对象适配器：
对应 ObjectAdapter 那个部分。NormalModelAdapter 和 SpecialModelAdapter 还是 CommonUsedAdapter 都继承自 BusinessCardAdapter 而 BusinessCardAdapter 有一个变量 weak var data:AnyObject? 。这data 是任意类型的变量 用来指向Model Normal 和 SpecialModel 需要适配的对象 。通过 重写协议中的方法来满足要求。如 SpecialModelAdapter 中的代码
override func lineColor() ->UIColor? {
letmodel:SpecialModel=self.dataas!SpecialModel
varcolor:UIColor=UIColor.black
//
switchmodel.colorString{
case"red":color =UIColor.red
case"green":color =UIColor.green
default:
color =UIColor.black
}returncolor}
客户端调用 ：
这里只 介绍万能适配器。其他的参考normalModelAdapterExample() specialModelAdapterExample()
这两个方法。调用后 效果如图2-2 所示： 改变不同的函数会有不同的效果
// commomUsedAdapter
privatefunccommonUsedAdapterExample(){
letdata1:NormalModel=NormalModel()
data1.name="DeLongYang"
data1.lineColor=UIColor.red
data1.phoneNumber="139-1447-8563"
letdata2:SpecialModel=SpecialModel()
data2.name="ShenZhen"
data2.colorString="green"
data2.phoneNumber="152-8456-8989"
letadapter:BusinessCardAdapter=CommonUsedAdapter(data: data1)
letcardView:BusinessCardView=BusinessCardView(frame:BUSINESS_FRAME)
cardView.center=self.view.center
cardView.loadData(data: adapter)
self.view.addSubview(cardView)
}
二者的比较：
●类适配器使用对象继承的方式，是静态的定义方式；而对象适配器使用对象组合的方式，是动态组合的方式。
●对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不可能再去处理 Adaptee的子类了。
对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。换言之，同一个适配器可以把源类和它的子类都适配到目标接口。因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。
●对于类适配器，适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现方法。
对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。
●对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee。
对于对象适配器，需要额外的引用来间接得到Adaptee。
建议尽量使用对象适配器的实现方式，多用合成/聚合、少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合的才是最好的。
适配器模式的优点
更好的复用性
系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。
更好的扩展性
在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。
适配器模式的缺点
过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
缺省适配器：
鲁智深的故事
和尚要做什么呢？吃斋、念经、打坐、撞钟、习武等。如果设计一个和尚接口，给出所有的和尚都需要实现的方法，那么这个接口应当如下：
protocol MookRouteProtocol {
func maigre()
func nianJing()
func daZuo()
func zhuangZhong()
func xiWu()
func getName() ->String
}
显然，所有的和尚类都应当实现接口所定义的全部方法，不然就根本通不过JAVA语言编辑器。像下面的鲁智深类就不行。
classLuZhiShen:NSObject,MookRouteProtocol{
funcmaigre() {
}
funcnianJing() {}........
由于鲁智深只实现了getName()和习武()方法，而没有实现任何其他的方法。因此，它根本就通不过Java语言编译器。鲁智深类只有实现和尚接口的所有的方法才可以通过Java语言编译器，但是这样一来鲁智深就不再是鲁智深了。以史为鉴，可以知天下。研究一下几百年前鲁智深是怎么剃度成和尚的，会对Java编程有很大的启发。不错，当初鲁达剃度，众僧说：“此人形容丑恶、相貌凶顽，不可剃度他",但是长老却说：”此人上应天星、心地刚直。虽然时下凶顽，命中驳杂，久后却得清净。证果非凡，汝等皆不及他。”
原来如此！看来只要这里也应上一个天星的话，问题就解决了！使用面向对象的语言来说，“应”者，实现也；“天星”者，抽象类也。也就是 这里的 TianXing 类。
鲁智深类继承抽象类“天星” class TrueLuZhiShen:TianXing 。 在Swift 中协议中的方法必需被实现。否则会报错。 和 Objective-C 中的还是有很大的不同 我们可以设置 可选方法 和 必须实现的方法。 为了通过编译器 。 我们使用了 默认适配器。 TianXing就是那个默认的适配器。
鲁智深实际上借助于适配器模式达到了剃度的目的。此适配器类实现了和尚接口所要求的所有方法。但是与通常的适配器模式不同的是，此适配器类给出的所有的方法的实现都是“平庸”的。这种“平庸化”的适配器模式称作缺省适配模式。
在很多情况下，必须让一个具体类实现某一个接口，但是这个类又用不到接口所规定的所有的方法。通常的处理方法是，这个具体类要实现所有的方法，那些有用的方法要有实现，那些没有用的方法也要有空的、平庸的实现。
这些空的方法是一种浪费，有时也是一种混乱。除非看过这些空方法的代码，程序员可能会以为这些方法不是空的。即便他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的，除非看过这些方法的源代码或是文档。
缺省适配模式可以很好的处理这一情况。可以设计一个抽象的适配器类实现接口，此抽象类要给接口所要求的每一种方法都提供一个空的方法。就像帮助了鲁智深的“上应天星”一样，此抽象类可以使它的具体子类免于被迫实现空的方法。
缺省适配模式的结构
缺省适配模式是一种“平庸”化的适配器模式。可以看到，接口AbstractService要求定义三个方法，分别是serviceOperation1()、serviceOperation2()、serviceOperation3()；而抽象适配器类ServiceAdapter则为这三种方法都提供了平庸的实现。因此，任何继承自抽象类ServiceAdapter的具体类都可以选择它所需要的方法实现，而不必理会其他的不需要的方法。
适配器模式的用意是要改变源的接口，以便于目标接口相容。缺省适配的用意稍有不同，它是为了方便建立一个不平庸的适配器类而提供的一种平庸实现。
在任何时候，如果不准备实现一个接口的所有方法时，就可以使用“缺省适配模式”制造一个抽象类，给出所有方法的平庸的具体实现。这样，从这个抽象类再继承下去的子类就不必实现所有的方法了。
