將乙個類的介面變換成客戶端所期待的另外一種介面，從而使原本因進口不相容而無妨一起工作的兩個類能夠在一起工作
怎麼來理解它呢？就是說，我想把乙個類的實現轉化成另外乙個類。舉個例子，現在有course類
public
class course
public string getcoursename()
}
public
class teacher
public
void
setteachername(string teachername)
}
1、定義乙個iteacher介面
public
inte***ce iteacher
public
class
teacher
implements
iteacher
//注意這裡的getteachername不是 get/set方法，
@override
public string getteachername()
}
a.首先要將course轉換成teacher，要實現iteacher介面/或者繼承teacher(不推薦使用繼承)
b.要獲取course的資訊，我們要有course物件，也就是說courseadapter要有乙個course成員或者繼承course
public
class
courseadapter
implements
iteacher
@override
public string getteachername()
}
public
class test
}
裝飾者模式中的裝飾者與介面卡中的介面卡角色相當，都是**了乙個類，他們的區別在於裝飾者模式**的是本型別附加一些額外的操作，介面卡模式中的介面卡**的不是本型別，他將執行轉交給了其他類。這也正是介面卡模式能夠完成適配的原因所在
a、策略模式 策略管理類 持有策略介面物件，操作交給策略物件來執行，它的關注點是 策略物件之間可以相互切換
b、**模式 **類 持有被**類的物件（這個物件可以在內部進行初始化，也可以在其他地方初始化，只不過被**物件是不安全的、可隨意更改的，就違背了**模式的初衷），操作交給被**者來執行，它的關注點在於對被**者的保護
c、實際，如果我們不讓設計模式先入為主的話，策略模式何嘗不是一種**呢？只是彼此的關注點不同
d、裝飾者模式 裝飾者在呼叫被裝飾者來執行操作前後插入一些行為，它的關注點在於增強/消弱被**類的功能
e、介面卡模式 將兩個類進行轉化，使之可以以同樣的方式來工作，它的關注點是轉移類的行為
f、實際上，設計模式一定要有乙個比較明確的寫法嗎？我認為這只是一種思想。這可以從策略和**模式的寫法差別中看出，難道我在策略管理類中來實現策略物件介面我就不能實現策略模式了嗎？所以這裡重要的是思想。
g、後面幾章看起來可能慢慢複雜起來，因為我們到目前為止，我們的**結構還是比較簡單的，基本都是具體依賴抽象，那麼如果我們讓抽象依賴抽象呢？ 會變成什麼樣了呢？
介面卡模式（類介面卡 物件介面卡）
做個筆記 引用 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...