The Principle of Least Knowledge 迪米特法則

talk only to your immediate friends.

概念上像是，在物件導向程式的方法中只與自己類別的朋友互動。所謂的朋友指的是以下對象：

1. 類別本身的成員變數
2. 呼叫方法時輸入的參數
3. 在這個方法中初始化的物件
4. 呼叫的物件本身

運用這個法則的優點是可以降低程式中不同類別耦合的程度，不會讓一個類別跟太多類別綁在一起，若是日後要調整才不會造成牽一髮動全身的窘境。
運用下面書中給的範例可以更好看懂，以下兩個類別分別有違反或是遵守迪米特法則的部分：

public House { 
    WeatherStation station;
    
    // other methods and constructor
    
    public float getTemp() {
        //這邊很明顯地違反迪米特法則，因為station用getThermometer()去拿到Thermometer，又再用Thermomenter拿到溫度
        return station.getThermometer().getTemperature();
    } 
}

在上面的範例中，用成員變數station拿到Thermometer是沒有問題的，就是朋友的一種。但是用return回來的Thermometer去呼叫getTemperature()，就超出前面定義朋友的範圍。

public House {
    WeatherStation station;
    
    // other methods and constructor
    public float getTemp() {
        Thermometer thermometer = station.getThermometer(); 
        return getTempHelper(thermometer);
    }
    
    public float getTempHelper(Thermometer thermometer) { 
        return thermometer.getTemperature();
    } 
}

這個範例中，先在getTemp()中初始化產生新的Thermometer，是定義的第一種朋友，接著呼叫getTempHelper()。由於getTempHelper() 用方法中的參數Thermometer得到溫度資料，符合剛剛定義的第二種朋友，所以這個範例並沒有違反原則。

參考資料：

1. 《深入淺出設計模式 (Head First Design Patterns) 》
2. 書中官方程式碼傳送門
3. https://fonu195713.github.io/docs/computer_science/design_pattern/least_knowledge_principle/

Disclaimer
因為讀的是原文版，所以難免會有翻譯詞不達意或是專有名詞上的差異，有錯誤的話歡迎在留言區一起交流！