我們的筆記本電腦的充電線上通常都會有一個大磚塊似得東西，這個東西是用來將家用額定電壓220V轉換成筆記本適用的電壓，它叫做變壓器，也叫做適配器。 今天要研究的是適配器模式，名副其實，中心思想也是建立一個適配器，將兩個不同的介面或者應用連接起來，讓他們能夠協作。這種協作有時並不是主動的，就是他們彼此都 ...
我們的筆記本電腦的充電線上通常都會有一個大磚塊似得東西，這個東西是用來將家用額定電壓220V轉換成筆記本適用的電壓，它叫做變壓器，也叫做適配器。
今天要研究的是適配器模式，名副其實，中心思想也是建立一個適配器，將兩個不同的介面或者應用連接起來，讓他們能夠協作。這種協作有時並不是主動的，就是他們彼此都不認識，只是通過適配器建立了合作通道而已。
適配器模式，將一個類的介面轉換成客戶希望的另外一個介面。Adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。
我們舉一個例子寫代碼：
一個班級的成績需要按照分數從大到小排名次。老師都是從成績類Grade中的getRankList方法獲得結果的，但是實現getRankList的演算法過時了，或者說效率較低，而這時候另外我們有效率較高的演算法QuickSort，但是由於雙方的介面定義不同，而又不想直接更改getRankList方法，同時QuickSort是一個通用介面，更不會隨意修改。
這時候就該適配器登場了，首先看客戶端如何調用：
package pattern.adapter;
public class Main {
public static void main(String[] args) {
Grade g = new Grade();
int[] grades = { 78, 75, 91, 81, 67, 32, 60, 59, 100, 74, 75 };
g.getRankList(grades);
}
}
Grade類的內部內容為：
package pattern.adapter;
public class Grade {
public int[] getRankList(int[] index) {
System.out.println("效率較低的演算法");
return index;
}
}
此時，我們希望在不改變原有介面getRankList和QuickSort的前提下，新增一個Adapter類繼承自Grade類，
package pattern.adapter;
import algorithms.sort.QuickSort;
import algorithms.sort.Sort;
public class GradeAdapter extends Grade {
private Sort s = new QuickSort();
@Override
public int[] getRankList(int[] index) {
index = s.sort(index);
s.show(index);
return index;
}
}
在Adapter類中，我們首先定義了一個類屬性QuickSort的實例，然後重寫了getRankList方法，改為調用了QuickSort的演算法。
原結果：
效率較低的演算法
現結果：
100
91
81
78
75
75
74
67
60
59
32
數組長度：11，執行交換次數：18
通過上面的代碼例子可以看到，Adapter的最佳使用時機不是在軟體從無到有的設計階段，而是在軟體的維護階段，當出現雙方都不太容易修改的時候使用適配器模式適配，符合“開閉原則”，對擴展開放，對修改關閉。
如果能實現預防介面不同的問題，不匹配的問題就不會發生，在有效的介面不統一問題發生時，及時重構，問題不至於擴大；只有碰到無法改變原有設計和代碼的情況時，才考慮適配。
事後控制不如事中控制，事中控制不如事前控制。
適配器模式是好模式，但如果不註意它的使用場合而盲目使用，就是本末倒置了。
參考資料：《大話設計模式》程傑著，《GoF》。
