介面卡模式是將目標物件的介面轉換為使用者所期望的另外乙個介面，使得原本介面型別不一致的類能夠更好的工作在一起。使用場景：兩個類所做的事情相同或相似，但是具有不同的介面時要使用它。客戶端可以統一呼叫同一介面，這樣應該可以更簡單、更直接、更緊湊。
假設現在要求寫乙個程式，這個程式示意乙個足球對的訓練過程。這個足球隊有著中方球員、外援。由於語言文化不同。中方球員和外籍球員的控制介面是不一致的。
# -*- coding: utf-8 -*-
class chinese_player:
def she_men(self):
print('射門！！！')
def fang_shou(self):
print('鏟球！！！')
class foreign_player:
def shooting(self):
print('shoot door!!!')
def defense(self):
print('tackle!!!')
class coach:
def __init__(self, *team_plays):
self._players = team_plays
def trainning(self):
for player in self._players:
if isinstance(player, foreign_player):
player.shooting()
player.defense()
elif isinstance(player, chinese_player):
player.she_men()
player.fang_shou()
# 如果有更多的不同介面型別的球員，則需要寫更多的分支
if __name__ == '__main__' :
# 客戶端
wulei = chinese_player()
elkeson = foreign_player()
lipe = coach(wulei,elkeson)
lipe.trainning()
主要的問題：
1> 當程式需要擴充套件，需要處理更多型別的球員時，coach 類的 trainning 函式需要不斷的去加分支。違反了開放封閉原則。
2> trainning中的isinstance介面，給人乙個明顯的訊號就是要識別具體的物件型別，根據具體的型別再做具體的操作。明顯的是依賴具體實現進行程式設計。違背了依賴倒置原則附：
依賴倒置原則dip(dependency inversion principle):高層模組不應該依賴於低層模組；二者都應該依賴於抽象。抽象不應該依賴於細節；細節應該依賴抽象。
要針對介面程式設計，而不是針對實現程式設計。
單一職責原則srp(single responsibility principle):就乙個邏輯單元(類、函式)而言，應該僅有乙個引起變化的原因。分離關注點；正交設計；
print('射門！！！')
def fang_shou(self):
print('鏟球！！！')
class foreign_player:
def shooting(self):
print('shoot door!!!')
def defense(self):
print('tackle!!!')
class translater:
def __init__(self):
self._player = chinese_player()
def shooting(self):
self._player.she_men()
def defense(self):
self._player.fang_shou()
class coach:
def __init__(self, *team_plays):
self._players = team_plays
def trainning(self):
# 無需再對player的型別做具體的判斷和處理，針對shooting defense通用介面變成。
for player in self._players:
player.shooting()
player.defense()
if __name__ == '__main__':
# 為中國球員請個洋翻譯：）
wulei = translater()
elkeson = foreign_player()
lipe = coach(wulei, elkeson)
lipe.trainning()
分析1> translater類作為乙個介面卡，實現了 she_men ->shooting fang_shou->defense 函式介面的對映，讓shooting 和 defense變為通用函式介面。
2> 有了介面卡的函式介面轉換，coach核心類的 trainning 介面，無需再做球員型別的具體判斷，只需要針對通用介面程式設計即可。後續的功能擴充套件，也無需再對training介面進行變更。
java設計模式6 介面卡模式（Adapter）
我們接著討論設計模式，上篇文章我講完了5種建立型模式，這章開始，我將講下7種結構型模式 介面卡模式 裝飾模式 模式 外觀模式 橋接模式 組合模式 享元模式。其中物件的介面卡模式是各種模式的起源，我們看下面的圖 介面卡模式將某個類的介面轉換成客戶端期望的另乙個介面表示，目的是消除由於介面不匹配所造成的...
Java設計模式五 介面卡模式 Adapter
將一類的介面轉換成客戶希望的另外乙個介面，adapter模式使得原本由於介面不相容而不能一起工作那些類可以一起工作。適用情況 使用的前提是 介面中規定了所有要實現的方法 但乙個要實現此介面的具體類，只用到了其中的幾個方法，而其它的方法都是沒有用的。實現方法 用乙個抽象類實現已有的介面，並實現介面中所...
設計模式 介面卡模式 類介面卡 物件介面卡
乙個小例子，便於理解，上 這是我們造的。現在想用這個方法。public class adaptee 類介面卡。對我們想要的方法封裝一下，target就能像之前一樣，呼叫request方法即可。public class adapter1 extends adaptee implements targe...