超越虛擬化 成就資訊化產品——"瑞友杯"虛擬化徵文
介面卡模式把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面不匹配而無法在一起工作的兩個類能夠在一起工作。
介面卡模式的用途
用電器做例子，膝上型電腦的插頭一般都是三相的，即除了陽極、陰極外，還有一個地極。而有些地方的電源插座 卻只有兩極，沒有地極。電源插座與膝上型電腦的電源插頭不匹配使得膝上型電腦無法使用。這時候一個三相到兩相的轉換器（介面卡）就能解決此問題，而這正像 是本模式所做的事情。
介面卡模式的結構
介面卡模式有類的介面卡模式和物件的介面卡模式兩種不同的形式。
類介面卡模式
類的介面卡模式把適配的類的API轉換成為目標類的API。
在上圖中可以看出，Adaptee類並沒有sampleOperation2()方法，而客戶端則期待這個方法。為使客戶端能夠使用 Adaptee類，提供一箇中間環節，即類Adapter，把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee 是繼承關係，這決定了這個介面卡模式是類的：
模式所涉及的角色有：
● 目標(Target)角色：這就是所期待得到的介面。注意：由於這裡討論的是類介面卡模式，因此目標不可以是類。
● 源(Adapee)角色：現在需要適配的介面。
● 介面卡(Adaper)角色：介面卡類是本模式的核心。介面卡把源介面轉換成目標介面。顯然，這一角色不可以是介面，而必須是具體類。
原始碼
public interface Target { /** * 這是源類Adaptee也有的方法 */public void sampleOperation1(); /** * 這是源類Adapteee沒有的方法 */public void sampleOperation2(); }
上面給出的是目標角色的原始碼，這個角色是以一個JAVA介面的形式實現的。可以看出，這個介面聲明瞭兩個方 法：sampleOperation1()和sampleOperation2()。而源角色Adaptee是一個具體類，它有一個 sampleOperation1()方法，但是沒有sampleOperation2()方法。
public class Adaptee { public void sampleOperation1(){} }
介面卡角色Adapter擴充套件了Adaptee,同時又實現了目標(Target)介面。由於Adaptee沒有提供sampleOperation2()方法，而目標介面又要求這個方法，因此介面卡角色Adapter實現了這個方法。
public class Adapter extends Adaptee implements Target { /** * 由於源類Adaptee沒有方法sampleOperation2() * 因此介面卡補充上這個方法 */ @Override public void sampleOperation2() { //寫相關的程式碼 } }
物件介面卡模式
與類的介面卡模式一樣，物件的介面卡模式把被適配的類的API轉換成為目標類的API，與類的介面卡模式不同的是，物件的介面卡模式不是使用繼承關係連線到Adaptee類，而是使用委派關係連線到Adaptee類。
從上圖可以看出，Adaptee類並沒有sampleOperation2()方法，而客戶端則期待這個方法。為使客戶端能夠使用 Adaptee類，需要提供一個包裝(Wrapper)類Adapter。這個包裝類包裝了一個Adaptee的例項，從而此包裝類能夠把Adaptee 的API與Target類的API銜接起來。Adapter與Adaptee是委派關係，這決定了介面卡模式是物件的。
原始碼
public interface Target { /** * 這是源類Adaptee也有的方法 */public void sampleOperation1(); /** * 這是源類Adapteee沒有的方法 */public void sampleOperation2(); }
public class Adaptee { public void sampleOperation1(){} }
public class Adapter { private Adaptee adaptee; public Adapter(Adaptee adaptee){ this.adaptee = adaptee; } /** * 源類Adaptee有方法sampleOperation1 * 因此介面卡類直接委派即可 */ public void sampleOperation1(){ this.adaptee.sampleOperation1(); } /** * 源類Adaptee沒有方法sampleOperation2 * 因此由介面卡類需要補充此方法 */ public void sampleOperation2(){ //寫相關的程式碼 } }
介面卡模式的變體
上面談到的所有介面卡都是通過重用Adaptee類從而實現Target介面中的方法。這只是具體層次的重用。是否還存在更高層次的介面卡呢！？答案是肯定的！我們不僅可以適配具體的類還可以適配抽象類，甚至適配介面！下面是這種適配的簡圖：
從上圖可以看出：Adapter將Adaptee介面適配為客戶Client需要的介面Target，這樣在整個系統中所有實現Adaptee介面的類都可以通過Adapter適配為Target物件，從而避免為每一個類都寫一個介面卡。我們不僅僅可以象上面一樣對介面進行適配，也可以對抽象類進行適配！主要是根據系統的需求，確定此時的場景是否適合使用介面卡模式！ 在IO中byte陣列到InputStream的適配。就當作一個介面卡的例子吧！其它關於介面卡在Java中的應用以及如何將java.sql.ResultSet適配至javax.swing.table.TableModel、將File、DOM樹、Thread適配至javax.swing.tree.TreeModel,android中ListView和RecycledView裡都大量使用介面卡模式,就不在這裡詳細講解了。
類介面卡和物件介面卡的權衡
● 類介面卡使用物件繼承的方式，是靜態的定義方式；而物件介面卡使用物件組合的方式，是動態組合的方式。
● 對於類介面卡，由於介面卡直接繼承了Adaptee，使得介面卡不能和Adaptee的子類一起工作，因為繼承是靜態的關係，當介面卡繼承了Adaptee後，就不可能再去處理 Adaptee的子類了。
● 對於物件介面卡，一個介面卡可以把多種不同的源適配到同一個目標。換言之，同一個介面卡可以把源類和它的子類都適配到目標介面。因為物件介面卡採用的是物件組合的關係，只要物件型別正確，是不是子類都無所謂。
● 對於類介面卡，介面卡可以重定義Adaptee的部分行為，相當於子類覆蓋父類的部分實現方法。
● 對於物件介面卡，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類來實現重定義，然後讓介面卡組合子類。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可同時適用於所有的源。
● 對於類介面卡，僅僅引入了一個物件，並不需要額外的引用來間接得到Adaptee。
● 對於物件介面卡，需要額外的引用來間接得到Adaptee。
建議儘量使用物件介面卡的實現方式，多用合成/聚合、少用繼承。當然，具體問題具體分析，根據需要來選用實現方式，最適合的才是最好的。
介面卡模式的優點
- 更好的複用性
系統需要使用現有的類，而此類的介面不符合系統的需要。那麼通過介面卡模式就可以讓這些功能得到更好的複用。
- 更好的擴充套件性
在實現介面卡功能的時候，可以呼叫自己開發的功能，從而自然地擴充套件系統的功能。
介面卡模式的缺點
過多的使用介面卡，會讓系統非常零亂，不易整體進行把握。比如，明明看到呼叫的是A介面，其實內部被適配成了B介面的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是很有必要，可以不使用介面卡，而是直接對系統進行重構。
預設適配模式
預設適配(Default Adapter)模式為一個介面提供預設實現，這樣子型別可以從這個預設實現進行擴充套件，而不必從原有介面進行擴充套件。作為介面卡模式的一個特例，預設是適配模式在JAVA語言中有著特殊的應用。
魯智深的故事
和尚要做什麼呢？吃齋、唸經、打坐、撞鐘、習武等。如果設計一個和尚介面，給出所有的和尚都需要實現的方法，那麼這個介面應當如下：
public interface 和尚 { public void 吃齋（）； public void 唸經（）； public void 打坐（）； public void 撞鐘（）； public void 習武（）； public String getName(); }
顯然，所有的和尚類都應當實現介面所定義的全部方法，不然就根本通不過JAVA語言編輯器。像下面的魯智深類就不行。
public class 魯智深 implements 和尚{ public void 習武(){ 拳打鎮關西； 大鬧五臺山； 大鬧桃花村； 火燒瓦官寺； 倒拔垂楊柳； } public String getName(){ return "魯智深"; } }
由於魯智深只實現了getName()和習武()方法，而沒有實現任何其他的方法。因此，它根本就通不過Java語言編譯器。魯智深類只有實現 和尚介面的所有的方法才可以通過Java語言編譯器，但是這樣一來魯智深就不再是魯智深了。以史為鑑，可以知天下。研究一下幾百年前魯智深是怎麼剃度成和 尚的，會對Java程式設計有很大的啟發。不錯，當初魯達剃度，眾僧說：“此人形容醜惡、相貌凶頑，不可剃度他",但是長老卻說：”此人上應天星、心地剛直。 雖然時下凶頑，命中駁雜，久後卻得清淨。證果非凡，汝等皆不及他。”
原來如此！看來只要這裡也應上一個天星的話，問題就解決了！使用面向物件的語言來說，“應”者，實現也；“天星”者，抽象類也。
public abstract class 天星 implements 和尚 { public void 吃齋(){} public void 唸經(){} public void 打坐(){} public void 撞鐘(){} public void 習武(){} public String getName(){ return null; } }
魯智深類繼承抽象類“天星”
public class 魯智深 extends 天星{ public void 習武(){ 拳打鎮關西； 大鬧五臺山； 大鬧桃花村； 火燒瓦官寺； 倒拔垂楊柳； } public String getName(){ return "魯智深"; } }
這個抽象的天星類便是一個介面卡類，魯智深實際上藉助於介面卡模式達到了剃度的目的。此介面卡類實現了和尚介面所要求的所有方法。但是與通常的介面卡模式不同的是，此介面卡類給出的所有的方法的實現都是“平庸”的。這種“平庸化”的介面卡模式稱作預設適配模式。
在很多情況下，必須讓一個具體類實現某一個介面，但是這個類又用不到介面所規定的所有的方法。通常的處理方法是，這個具體類要實現所有的方法，那些有用的方法要有實現，那些沒有用的方法也要有空的、平庸的實現。
這些空的方法是一種浪費，有時也是一種混亂。除非看過這些空方法的程式碼，程式設計師可能會以為這些方法不是空的。即便他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的，除非看過這些方法的原始碼或是文件。
預設適配模式可以很好的處理這一情況。可以設計一個抽象的介面卡類實現介面，此抽象類要給介面所要求的每一種方法都提供一個空的方法。就像幫助了魯智深的“上應天星”一樣，此抽象類可以使它的具體子類免於被迫實現空的方法。
預設適配模式的結構
預設適配模式是一種“平庸”化的介面卡模式。
public interface AbstractService { public void serviceOperation1(); public int serviceOperation2(); public String serviceOperation3(); }
public class ServiceAdapter implements AbstractService{ @Override public void serviceOperation1() { } @Override public int serviceOperation2() { return 0; } @Override public String serviceOperation3() { return null; } }
可以看到，介面AbstractService要求定義三個方法，分別是serviceOperation1()、serviceOperation2()、serviceOperation3()；而抽象介面卡類ServiceAdapter則為這三種方法都提供了平庸的實現。因此，任何繼承自抽象類ServiceAdapter的具體類都可以選擇它所需要的方法實現，而不必理會其他的不需要的方法。
介面卡模式的用意是要改變源的介面，以便於目標介面相容。預設適配的用意稍有不同，它是為了方便建立一個不平庸的介面卡類而提供的一種平庸實現。
在任何時候，如果不準備實現一個介面的所有方法時，就可以使用“預設適配模式”製造一個抽象類，給出所有方法的平庸的具體實現。這樣，從這個抽象類再繼承下去的子類就不必實現所有的方法了。
轉載於:https://my.oschina.net/fuyong/blog/727520