你看了看日期，不是吧！這**是馬上要開始了，分明是已經開始了！這怎麼可能來得及呢？
「沒關係的。」你的leader安慰你道：「功能其實很簡單的，介面都已經提供好了，你只需要呼叫一下就行了。」
好吧，你勉為其難地接受了，對於這種突如其來的新需求，你早已習慣。
好吧，聽起來功能並不是很複雜，如果現在就開始動工好像還來得及，於是你馬上敲起了**。
public
inte***ce playercount
public
class
serverone
implements
playercount
@override
public
intgetplayercount()
}
public
class
servertwo
implements
playercount
@override
public
intgetplayercount()
}
public
class
serverthree
implements
playercount
@override
public
intgetplayercount()
}
public
class xmlbuilder
}
xmlbuilder.buildxml(new serverone());xmlbuilder.buildxml(new servertwo());xmlbuilder.buildxml(new serverthree());「晤。。。本來應該是這樣的。。。可是，utility和serverfirst這兩個類都已經被打到jar包裡了，沒法修改啊。。。」你的leader有些為難。
「什麼？這不是坑爹嗎，難道要我把介面給改了？」你已經淚流滿面了。
「這倒不用，這種情況下可以使用介面卡模式，這個模式就是為了解決介面之間不相容的問題而出現的。」
其實介面卡模式的使用非常簡單，核心思想就是只要能讓兩個互不相容的介面能正常對接就行了。上面的**中，xmlbuilder中使用playercount這個介面來拼裝xml，而serverfirst並沒有實現playercount這個介面，這個時候就需要乙個介面卡類來為xmlbuilder和serverfirst之間搭起一座橋梁，毫無疑問，serverone就將充當介面卡類的角色。修改serverone的**，如下所示：
public
class
serverone
implements
playercount
@override
public string getservername()
@override
public
intgetplayercount()
}
需要值得注意的一點是，介面卡模式不並是那種會讓架構變得更合理的模式，更多的時候它只是充當救火隊員的角色，幫助解決由於前期架構設計不合理導致的介面不匹配的問題。更好的做法是在設計的時候就盡量把以後可能出現的情況多考慮一些，在這個問題上不要向你的leader學習。
介面卡：將乙個類的介面轉換成客戶希望的另外乙個介面。介面卡模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。
設計模式之介面卡模式（類介面卡模式）
介面卡模式，即定義乙個包裝類，用於包裝不相容介面的物件 包裝類 介面卡adapter 被包裝物件 適配者adaptee 被適配的類 把乙個類的介面變換成客戶端所期待的另一種介面，從而使原本介面不匹配而無法一起工作的兩個類能夠在一起工作。介面卡模式的形式分為 類的介面卡模式和物件的介面卡模式 模式原理...
設計模式之 介面卡模式
1，介面卡模式把乙個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面不匹配而無法一起工作的兩個類能夠在一起工作 2，介面卡模式有兩種 1 類的介面卡模式 介面卡類繼承源類 這樣介面卡類就繼承了源類有的方法 並實現目標介面，實現在源類中沒有而在介面中有的方法，從而實現介面卡類有目標介面的所有方...
設計模式之介面卡模式
介面卡模式定義 將乙個類的介面，轉換成客戶期望的另乙個介面。介面卡讓原本介面不相容的類可以合作無間。簡單定義 封裝物件，並提供不同的介面。簡單例子 鴨子介面 package headfirst.adapter.ducks public inte ce duck 具體鴨子 package headfi...