介面卡模式（Adapter）：可以想想現實生活中的轉換插頭。介面卡是一箇中間層，能將類的介面轉換成想要的介面。這與前文中的裝飾者模式有點像，不過裝飾者模式是賦予介面新的功能，而介面卡模式則把介面轉換成需要的樣子。 我的理解比較簡單：假設我們手頭有兩個介面A和B。有一個類C需要使用介面B的方法，但是在某些情況下介面A中的一些功能更適合C，此時我們定義一個介面卡類，包含一個A的物件，並用它實現B的介面。然後我們把這個介面卡傳給C。這樣對於C來說它依然只調用B中的方法，但是實際上這些方法是由A的物件實現的。介面卡起到一箇中間人的角色。 書中舉了一個JAVA的例子：早期java 的集合類都實現了Enumeration介面，但是某一版本後的集合類改為實現Iterator介面。比起Enumeration，Iterator除了提供遍歷元素的功能還提供了remove功能。 現在的問題是，很多舊程式碼使用了Enumeration，而我們現在在新程式碼中只希望用到Iterator，此時我們可以使用一個介面卡。程式碼大略是這樣：

public class EnumerationIterator implements Iterator {
    Enumeration enumeration;

    public EnumerationIterator(Enumeration enumeration) {
        this.enumeration = enumeration;
    }

    public boolean hasNext() {
        return enumeration.hasMoreElements();
    }

    public Object next() {
        return enumeration.nextElement();
    }

    public void remove() {
        throw new UnsupportedOperationException();
    }
}
 

請注意對於remove的處理。
還有一個模式能改變介面，但是目的是把一系列操作隱藏起來，只提供使用者感興趣的功能呼叫。它就是外觀模式（facade pattern）。 比如要實現看dvd的操作，需要開啟電視機，開啟影碟機，調整音量等等，很多步驟。我們可以將這一系列操作使用外觀模式整合（使用組合的方式，及外觀類中包含涉及到的所有物件：電視機，影碟機等等）到一起，然後只提供一個“看dvd”的介面供使用者呼叫就好了。這讓我想起了MVC模式，總之是添加了一個業務邏輯層來簡化操作，並且使客戶與實際裝置解耦（比如如果電視升級了，操作有所改變，我們只需要更改外觀類中的程式碼，而不必煩擾客戶呼叫了）。
設計原則：最少知識原則，只調用與自己最親密的物件的方法。如果在一個方法中，物件O是呼叫方法M的返回結果，那麼儘量不要呼叫O的方法，因為這會產生對其它物件的子部分的依賴。此時，最好能在M中提供一個更直接的方法。