思考題

想想看，你在 JavaAPI 中遇到過哪些外觀，你還希望 Java 能夠新增哪些外觀？ P262

• println、log 日誌介面、JDBC 介面
• 突然讓想感覺想不出來，各種 API 都用得挺順的，沒有太麻煩的使用

外觀模式

提供了一個統一的介面，用來訪問子系統中的一群介面。外觀定義了一個高層介面，讓子系統更容易使用。 P264

特點

• 提供簡化的介面的同時，依然將系統完整的功能暴露出來 P260
• 將客戶從元件的子系統中解耦 P260
• 意圖是提供子系統的一個簡化介面 P260

區別 P270

• 介面卡模式：將一個物件包裝起來以改變其介面
• 裝飾器模式：將一個物件包裝起來以增加新的行為和責任
• 外觀模式：將一群物件“包裝”起來以簡化其介面

設計原則

最少知識原則：只和你的密友談話。即減少物件之間的互動，減少類的耦合。 P265

優點

• 減少軟體的維護成本 P267

缺點

• 導致製造更多的“包裝”類 P267
• 導致增加複雜度和開發時間 P267
• 降低執行時的效能 P267

遵循最少知識原則的方針

對於任何物件，在該物件的方法內，我們只應該呼叫屬於以下範圍的方法： P266

• 該物件本身
• 被當作方法的引數而傳遞進來的物件
• 此方法所建立或例項化的任何物件
• 物件的任何元件

由前三條可知：不要呼叫其他方法返回結果的方法

思考題

這些類有沒有違反最少知識原則？請說明原因。 P268

public class House {
    WeatherStation station;
    
    // 其他的方法和構造器
    
    public float getTemp() {
        return station.getThermometer().getTemperature();
    }
    // 違反了最少知識原則
    // 呼叫了方法返回結果的方法
}

public class Houst {
    WeatherStation station;

    // 其他的方法和構造器
    
    public float getTemp() {
        Thermometer thermometer = station.getThermometer();
        return getTempHelper(thermometer);
    }
    // 沒有違反最少知識原則
    // 只調用了物件的元件以及物件本身的方法
    
    public float getTempHelper(Thermometer thermometer) {
        return thermometer.getTemperature();
    }
    // 只調用了引數
}
 

所思所想

• 大部分介面功能的封裝應該都算使用了外觀模式。比如說下單操作，對外只暴露了一個下單介面，但內部其實有大量的子元件呼叫（購物車介面、運費計算介面、優惠券介面、地址介面、下單中介軟體、物流介面等）。再比如一個簡單println，內部就包含了併發控制、異常捕獲、呼叫BufferedWriter物件進行輸出控制等。

本文首發於公眾號：滿賦諸機（點選檢視原文） 開源在 GitHub ：reading-notes/head-first-design-patterns