這篇文章主要為大家詳細介紹了java設計模式之適配器模式筆記，具有一定的參考價值，有興趣的小夥伴們可以參考一下
適配器（Adapter）模式：
適配器模式把一個類別的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。
生活中的場景：
1、筆記型電腦電源轉接器，可以將220v轉換為適合筆電使用的電壓。
2、給筆記型電腦的usb介面插入桌上型電腦的ps/2介面的鍵盤，需要一個usb和ps/2的介面轉接器，此時usb和ps/2的介面轉接器就充當了適配器的角色。
通用類別圖：
# 在上面的通用類別圖中，Cient 類最後面對的是Target 介面（或抽象類別），它只能夠使用符合此目標標準的子類別；而Adaptee 類別則是被適配的物件（也稱為來源角色），因為它包含specific （特殊的）操作、功能等，所以我們想要在自己的系統中使用它，將其轉換成符合我們標準的類，使得Client 類可以在透明的情況下任意選擇使用ConcreteTarget 類或是具有特殊功能的Adaptee 類。
適配器模式中的角色：
目標介面(Target)：客戶所期待得到的介面。目標可以是具體的或抽象的類，也可以是介面。
需要適配的類別(Adaptee)：需要適配的介面或適配類別。
適配器(Adapter)：適配器類別是本模式的核心。適配器透過包裝一個需要適配的對象，把來源介面轉換成目標介面。顯然，這一角色不可以是接口，而必須是具體類別。
適配器模式的結構：
適配器模式有類別的適配器模式和物件的適配器模式兩種不同的形式。
類別的適配器模式把適配的類別的API轉換成為目標類別的API。
物件的適配器模式與類別的適配器模式一樣，物件的適配器模式把被適配器的類別的API轉換成為目標類別的API，與類別的適配器模式不同的是，物件的適配器模式不是使用繼承關係連接到Adaptee類，而是使用委派關係連接到Adaptee類別。
類別的適配器模式
1、建立一個被適應的類別：
/**
* 被适配的类
* 已存在的、具有特殊功能、但不符合我们既有的标准接口的类
* (相当于例子中的，PS/2键盘)
* @author ChuanChen
*
*/
public class Adaptee {
public void specificRequest(){
System.out.println("可以完成客户请求的需要的功能！");
}
}2、建立一個目標接口，能處理一些特殊請求
/**
* 目标接口，或称为标准接口
* @author ChuanChen
*
*/
public interface Target {
void handleReq();
}3、建立一個適配器(類別適配器方式)
/**
* 适配器 (类适配器方式)
* (相当于usb和ps/2的转接器)
* @author ChuanChen
*
*/
public class Adapter extends Adaptee implements Target {
@Override
public void handleReq() {
super.specificRequest();
}
}4、建立一個客戶端
/**
* 客户端类
* (相当于例子中的笔记本，只有USB接口)
* @author ChuanChen
*
*/
public class Client {
public void test(Target t){
t.handleReq();
}
public static void main(String[] args) {
Client c = new Client();
Adaptee a = new Adaptee();
Target t = new Adapter();
c.test(t);
}
}上面這種實作的適配器稱為類別適配器，因為Adapter 類別既繼承了Adaptee （被適配類別），也實作了Target 介面（因為Java 不支援多重繼承，所以這樣來實作），在Client 類別中我們可以根據需要選擇並建立任一種符合需求的子類，來實作具體功能。
物件的適配器模式
1、建立一個被適應的類別：
/**
* 被适配的类
* 已存在的、具有特殊功能、但不符合我们既有的标准接口的类
* (相当于例子中的，PS/2键盘)
* @author ChuanChen
*
*/
public class Adaptee {
public void specificRequest(){
System.out.println("可以完成客户请求的需要的功能！");
}
}2、建立一個目標接口，能處理一些特殊請求
/**
* 目标接口，或称为标准接口
* @author ChuanChen
*
*/
public interface Target {
void handleReq();
}3、建立一個適配器(物件適配器方式,使用了組合的方式跟被適配器整合)
/**
* 适配器 (对象适配器方式,使用了组合的方式跟被适配对象整合)
* (相当于usb和ps/2的转接器)
* @author ChuanChen
*
*/
public class Adapter implements Target{
private Adaptee adaptee;
@Override
public void handleReq() {
adaptee.specificRequest();
}
public Adapter(Adaptee adaptee) {
super();
this.adaptee = adaptee;
}
}4、建立一個客戶端
/**
* 客户端类
* (相当于例子中的笔记本，只有USB接口)
* @author ChuanChen
*
*/
public class Client {
public void test(Target t){
t.handleReq();
}
public static void main(String[] args) {
Client c = new Client();
Adaptee a = new Adaptee();
Target t = new Adapter(a);
c.test(t);
}
}我們只需要修改Adapter 類別的內部結構，即Adapter 本身必須先擁有一個被適配類的對象，再把具體的特殊功能委託給這個對象來實現。使用物件適配器模式，可以使得Adapter 類別（適配類別）根據傳入的Adaptee 物件達到適配多個不同被適配類別的功能，當然，此時我們可以為多個被適配器類別提取出一個接口或抽象類別。這樣看起來的話，似乎物件適配器模式更有彈性一點。
類別適配器和物件適配器的權衡：
#類別適配器使用物件繼承的方式，是靜態的定義方式；而物件適配器使用物件組合的方式，是動態組合的方式。
對於類別適配器，由於適配器直接繼承了Adaptee，使得適配器不能和Adaptee的子類別一起工作，因為繼承是靜態的關係，當適配器繼承了Adaptee後，就不可能再去處理Adaptee的子類別了。
對於物件適配器，一個適配器可以把多種不同的來源轉接到同一個目標。換言之，同一個適配器可以把來源類別和它的子類別都適配到目標介面。因為物件適配器採用的是物件組合的關係，只要物件類型正確，是不是子類別都無所謂。
對於類別適配器，適配器可以重定義Adaptee的部分行為，相當於子類別覆寫父類別的部分實作方法。
對於物件適配器，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類別來實作重定義，然後讓適配器組合子類別。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可同時適用於所有的來源。
對於類別適配器，僅僅引入了一個對象，並不需要額外的引用來間接得到Adaptee。
對於物件適配器，需要額外的參考來間接得到Adaptee。
建議盡量使用物件適配器的實作方式，多用合成/聚合、少用繼承。當然，具體問題具體分析，根據需要來選用實現方式，最適合的才是最好的。
適配器模式的優點：
#更好的複用性：
#系統需要使用現有的類，而此類的介面不符合系統的需要。那麼透過適配器模式就可以讓這些功能得到更好的複用。
更好的擴充：
#在實作適配器功能的時候，可以呼叫自己開發的功能，從而自然地擴展系統的功能。
適配器模式的缺點
過多的使用適配器，會讓系統非常零亂，不易整體進行掌握。例如，明明看到呼叫的是A接口，其實內部被適配成了B接口的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是有必要，可以不使用適配器，而是直接對系統進行重構。
適配器模式在工作中的場景：
1、已經存在的類別的介面不符合我們的需求；
2、建立一個可以重複使用的類，使得該類可以與其他不相關的類或不可預見的類（即那些接口可能不一定兼容的類）協同工作；
3、在不對每一個都進行子類化以匹配它們的在介面的情況下，使用一些已經存在的子類別。
適配器模式經常用於舊系統改造和升級。如果我們的系統開發之後再也不需要維護，那麼很多模式都是沒有必要的。但是不幸的是，事實上維護一個系統的代價往往是開發一個系統的數倍。
以上是Java設計模式中適配器模式的圖解的詳細內容。更多資訊請關注PHP中文網其他相關文章！
