介面卡模式，即根據客戶端需要，將某個類的介面轉換成特定樣式的介面，以解決類之間的相容問題。
如果我們的**依賴一些外部的api
，或者依賴一些可能會經常更改的類
，那麼應該考慮用介面卡模式。
下面我們以整合支付寶支付功能為例。
假設支付寶支付類的功能如下：
/**
* 支付寶支付類
*/class
alipay
}// 客戶端**
$alipay = new alipay();
$alipay->sendpayment();
alipay類完成支付功能，這樣的客戶端**可能很多。
一段時間後，如果支付寶的alipay類公升級，方法名由sendpayment()變成gopayment()會怎樣？
所有用了sendpayment()的客戶端**都要改變。
如果alipay類頻繁公升級，或者客戶端在很多地方使用，這會是極大的工作量。
現在我們用介面卡模式來解決。
我們在客戶端和alipay類之間加乙個中間類，也就是介面卡類，轉換原始的alipay為客戶端需要的形式。
為讓客戶端能呼叫到統一的類方法，我們先定義乙個介面卡介面：
/**
* 介面卡介面，所有的支付介面卡都需實現這個介面。
* 不管第三方支付實現方式如何，對於客戶端來說，都
* 用pay()方法完成支付
*/inte***ce
payadapter
alipay類我們無法控制，而且它有可能經常更新，所以我們不對它做任何修改。
我們新建乙個alipayadapter介面卡類，在pay()中轉換alipay的支付功能，如下：
/**
* 支付寶介面卡
*/class
alipayadapter
implements
payadapter
}
// 客戶端**
$alipay = new alipayadapter();
// 用pay()方法實現支付
$alipay->pay();
alipay的支付方法改變，只需要修改alipayadapter類就可以了。
有了介面卡後，擴充套件也變得更容易了。
**如下：
/**
*/class
wechatpay
public
function
dopay()}
/** */
class
wechatpayadapter
implements
payadapter
}
// 客戶端**
$wechat = new wechatpayadapter();
// 也是用pay()方法實現支付
$wechat->pay();
如果它們的api有變化，我們僅需修改客戶端依賴的介面卡類就可以，不用修改、暴露第三方類本身。
以上介面卡模式的**對應uml如下：
注意：介面卡模式中，介面卡類的名稱和建立方式一定是不會頻繁改動的。
對於客戶端來說，引用介面卡類的方式應該是統一而不變的，這才算是正確使用介面卡。
大的應用都會不斷地加入新庫和新api。
為避免它們的變更引發問題，應該用介面卡模式包裝起來，提**用統一的引用方式。
它會讓我們的**更具結構化，便於管理和擴充套件。
介面卡模式（類介面卡 物件介面卡）
做個筆記 引用 public inte ce usb public inte ce psp public class usber implements usb 類介面卡 psp適用usb介面 public class usbadapter extends usber implements psp 物...
介面卡模式 預設介面卡，類介面卡，物件介面卡
模式思想 改變乙個類的對外介面 增加或減少 以滿足不同外部呼叫者的需求 角色成員 目標介面 target 客戶所期待的介面。目標可以是具體的或抽象的類，也可以是介面。需要適配的類 adaptee 需要適配的類或適配者類。介面卡 adapter 通過包裝乙個需要適配的物件，把原介面轉換成目標介面。適配...
設計模式 介面卡模式 類介面卡 物件介面卡
乙個小例子，便於理解，上 這是我們造的。現在想用這個方法。public class adaptee 類介面卡。對我們想要的方法封裝一下，target就能像之前一樣，呼叫request方法即可。public class adapter1 extends adaptee implements targe...