前言：
在軟件設(shè)計中，已有的類與新接口之間不兼容的問題相當常見，同時，我們又不想為新的接口而重寫現(xiàn)有的類。此時，就需要用到“適配器模式”。定義：將一個類的接口轉(zhuǎn)換為客戶希望的另一個接口，它使得原來由于兼容問題不能一起工作的那些類可以一起工作。（《設(shè)計模式》，Addison Wesley，1994）。通常，適配器模式有兩種實現(xiàn)方式：類適配器，對象適配器 ，還有默認適配器模式。 百度百科中 關(guān)于適配器模式介紹的比較好，通俗易懂?百度百科適配器模式地址。
適配器模式的用途：
用電器做例子，筆記本電腦的插頭一般都是三相的，即除了陽極、陰極外，還有一個地極。而有些地方的電源插座卻只有兩極，沒有地極。電源插座與筆記本電腦的電源插頭不匹配使得筆記本電腦無法使用。這時候一個三相到兩相的轉(zhuǎn)換器（適配器）就能解決此問題，而這正像是本模式所做的事情。適配器模式的結(jié)構(gòu)適配器模式有類的適配器模式和對象的適配器模式兩種不同的形式。下面我們將通過一個?DEMO下載地址? 項目使用swift 編寫 。來說明這兩種適配器模式，對比二者的優(yōu)劣。 如下圖所示項目的目錄結(jié)構(gòu)。
類適配器：
在整個項目中：
BusinessCardView ：是我們的Client 。它只需要name，lineColor，phoneNumber 這三種String ，Color，String 類型的變量。 但是我們有兩個Model Normal 和 SpecialModel。 其中 SpecialModel的數(shù)據(jù)并不能直接滿足Client的需求。是需要適配的對象
classSpecialModel:NSObject{
varname:String=""
/// 很明顯 這個 colorString 和normalModel 中的 UIColor 屬性是有區(qū)別的
varcolorString:String=""
//
varphoneNumber:String=""
}
為了使二者都能使用。 我們新增了 protocolBusinessCardAdapterProtocol? 來對應(yīng)Client 。?
protocolBusinessCardAdapterProtocol {
funcname() ->String?
funclineColor() ->UIColor?
funcphoneNumber() ->String?
}
如圖1-1? 是ClassAdapter 模塊。AdapterNormalModel 和 AdapterSpecialModel 分別繼承自NormalModel 和 SpecialModel 并且執(zhí)行了BusinessCardAdapterProtocol? 協(xié)議。在執(zhí)行協(xié)議方法過程中做出改變。
funclineColor() ->UIColor? {
varcolor:UIColor= UIColor.black
//
switchself.colorString {
case"red":color = UIColor.red
case"green":color = UIColor.green
default:
color = UIColor.black
}return? color}
客戶端調(diào)用代碼：
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)
}
以上就是類適配器的思想。
對象適配器：
對應(yīng) ObjectAdapter 那個部分。NormalModelAdapter? 和? SpecialModelAdapter 還是 CommonUsedAdapter 都繼承自 BusinessCardAdapter? 而 BusinessCardAdapter 有一個變量 weak var data:AnyObject?? 。這data 是任意類型的變量 用來指向Model Normal 和 SpecialModel 需要適配的對象 。通過 重寫協(xié)議中的方法來滿足要求。如 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}
客戶端調(diào)用 ：
這里只 介紹萬能適配器。其他的參考normalModelAdapterExample()? specialModelAdapterExample()
這兩個方法。調(diào)用后 效果如圖2-2 所示： 改變不同的函數(shù)會有不同的效果
// 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)
}
二者的比較：
●類適配器使用對象繼承的方式，是靜態(tài)的定義方式；而對象適配器使用對象組合的方式，是動態(tài)組合的方式。
●對于類適配器，由于適配器直接繼承了Adaptee，使得適配器不能和Adaptee的子類一起工作，因為繼承是靜態(tài)的關(guān)系，當適配器繼承了Adaptee后，就不可能再去處理? Adaptee的子類了。
對于對象適配器，一個適配器可以把多種不同的源適配到同一個目標。換言之，同一個適配器可以把源類和它的子類都適配到目標接口。因為對象適配器采用的是對象組合的關(guān)系，只要對象類型正確，是不是子類都無所謂。
●對于類適配器，適配器可以重定義Adaptee的部分行為，相當于子類覆蓋父類的部分實現(xiàn)方法。
對于對象適配器，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類來實現(xiàn)重定義，然后讓適配器組合子類。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可同時適用于所有的源。
●對于類適配器，僅僅引入了一個對象，并不需要額外的引用來間接得到Adaptee。
對于對象適配器，需要額外的引用來間接得到Adaptee。
建議盡量使用對象適配器的實現(xiàn)方式，多用合成/聚合、少用繼承。當然，具體問題具體分析，根據(jù)需要來選用實現(xiàn)方式，最適合的才是最好的。
適配器模式的優(yōu)點
更好的復(fù)用性
系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。那么通過適配器模式就可以讓這些功能得到更好的復(fù)用。
更好的擴展性
在實現(xiàn)適配器功能的時候，可以調(diào)用自己開發(fā)的功能，從而自然地擴展系統(tǒng)的功能。
適配器模式的缺點
過多的使用適配器，會讓系統(tǒng)非常零亂，不易整體進行把握。比如，明明看到調(diào)用的是A接口，其實內(nèi)部被適配成了B接口的實現(xiàn)，一個系統(tǒng)如果太多出現(xiàn)這種情況，無異于一場災(zāi)難。因此如果不是很有必要，可以不使用適配器，而是直接對系統(tǒng)進行重構(gòu)。
缺省適配器：
魯智深的故事
和尚要做什么呢？吃齋、念經(jīng)、打坐、撞鐘、習(xí)武等。如果設(shè)計一個和尚接口，給出所有的和尚都需要實現(xiàn)的方法，那么這個接口應(yīng)當如下：
protocol MookRouteProtocol {
func maigre()
func nianJing()
func daZuo()
func zhuangZhong()
func xiWu()
func getName() ->String
}
顯然，所有的和尚類都應(yīng)當實現(xiàn)接口所定義的全部方法，不然就根本通不過JAVA語言編輯器。像下面的魯智深類就不行。
classLuZhiShen:NSObject,MookRouteProtocol{
funcmaigre() {
}
funcnianJing() {}........
由于魯智深只實現(xiàn)了getName()和習(xí)武()方法，而沒有實現(xiàn)任何其他的方法。因此，它根本就通不過Java語言編譯器。魯智深類只有實現(xiàn)和尚接口的所有的方法才可以通過Java語言編譯器，但是這樣一來魯智深就不再是魯智深了。以史為鑒，可以知天下。研究一下幾百年前魯智深是怎么剃度成和尚的，會對Java編程有很大的啟發(fā)。不錯，當初魯達剃度，眾僧說：“此人形容丑惡、相貌兇頑，不可剃度他",但是長老卻說：”此人上應(yīng)天星、心地剛直。雖然時下兇頑，命中駁雜，久后卻得清凈。證果非凡，汝等皆不及他。”
原來如此！看來只要這里也應(yīng)上一個天星的話，問題就解決了！使用面向?qū)ο蟮恼Z言來說，“應(yīng)”者，實現(xiàn)也；“天星”者，抽象類也。也就是 這里的 TianXing 類。
魯智深類繼承抽象類“天星”? class TrueLuZhiShen:TianXing 。? 在Swift 中協(xié)議中的方法必需被實現(xiàn)。否則會報錯。? 和 Objective-C 中的還是有很大的不同 我們可以設(shè)置 可選方法 和 必須實現(xiàn)的方法。 為了通過編譯器 。 我們使用了 默認適配器。 TianXing就是那個默認的適配器。
魯智深實際上借助于適配器模式達到了剃度的目的。此適配器類實現(xiàn)了和尚接口所要求的所有方法。但是與通常的適配器模式不同的是，此適配器類給出的所有的方法的實現(xiàn)都是“平庸”的。這種“平庸化”的適配器模式稱作缺省適配模式。
在很多情況下，必須讓一個具體類實現(xiàn)某一個接口，但是這個類又用不到接口所規(guī)定的所有的方法。通常的處理方法是，這個具體類要實現(xiàn)所有的方法，那些有用的方法要有實現(xiàn)，那些沒有用的方法也要有空的、平庸的實現(xiàn)。
這些空的方法是一種浪費，有時也是一種混亂。除非看過這些空方法的代碼，程序員可能會以為這些方法不是空的。即便他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的，除非看過這些方法的源代碼或是文檔。
缺省適配模式可以很好的處理這一情況?？梢栽O(shè)計一個抽象的適配器類實現(xiàn)接口，此抽象類要給接口所要求的每一種方法都提供一個空的方法。就像幫助了魯智深的“上應(yīng)天星”一樣，此抽象類可以使它的具體子類免于被迫實現(xiàn)空的方法。
缺省適配模式的結(jié)構(gòu)
缺省適配模式是一種“平庸”化的適配器模式?？梢钥吹剑涌贏bstractService要求定義三個方法，分別是serviceOperation1()、serviceOperation2()、serviceOperation3()；而抽象適配器類ServiceAdapter則為這三種方法都提供了平庸的實現(xiàn)。因此，任何繼承自抽象類ServiceAdapter的具體類都可以選擇它所需要的方法實現(xiàn)，而不必理會其他的不需要的方法。
適配器模式的用意是要改變源的接口，以便于目標接口相容。缺省適配的用意稍有不同，它是為了方便建立一個不平庸的適配器類而提供的一種平庸實現(xiàn)。
在任何時候，如果不準備實現(xiàn)一個接口的所有方法時，就可以使用“缺省適配模式”制造一個抽象類，給出所有方法的平庸的具體實現(xiàn)。這樣，從這個抽象類再繼承下去的子類就不必實現(xiàn)所有的方法了。
