又叫最少知識原則：如果兩個類別不必直接通訊，就不該發生直接互動；真要呼叫，透過第三者轉發。核心是「只跟直接朋友說話」——盡量降低成員可見度、強調類別間鬆耦合，因為資訊的隱藏促進了複用。
🧠 When to Use
TIP
訊號：出現 a.getB().getC().doD() 這種「火車失事（train wreck）」鏈；一個物件要辦事得先認識另一個物件肚子裡的第三、第四個物件；改了深處某個類別，一路上的呼叫端全被波及。
- 呼叫鏈穿透好幾層物件內部結構——你依賴的其實是別人的實作細節。
- 想降低類別間耦合、把「誰認識誰」收斂到最少。
- 有一群協作對象，想用一個窗口／中介把彼此的直接依賴打散成星形。
⚖️ Structure & Variants
只跟直接朋友說話 — 別問陌生人
// ❌ 火車失事：Checkout 認識了 Customer 內部的 Wallet、再認識 Wallet 內部的餘額
class Checkout {
fun pay(customer: Customer, amount: Int) {
customer.getWallet().getBalance().deduct(amount) // 穿三層內部結構
}
}
// ✅ 只跟直接朋友（Customer）說話，內部怎麼扣由它自己負責
class Checkout {
fun pay(customer: Customer, amount: Int) {
customer.pay(amount) // Customer 對外只暴露一個意圖
}
}- 「打電話別問『小張在嗎？』（依賴具體實作），要問『IT 部嗎？我電腦壞了請派人來』（依賴抽象窗口）」——大話設計模式的比喻。
兩個前提 — 降可見度 + 鬆耦合
- 降低成員的訪問權限：每個類別盡量把狀態包成
private，不需要外部知道的欄位／行為就別公開；對外只開必要的屬性。 - 強調鬆耦合：類別間耦合越弱越有利複用；弱耦合的類別被改，不會波及有關係的類別。
- 一句話總結書中觀點：資訊的隱藏促進了軟體的複用。
和三個原則／模式的關係
⚠️ Misuse & Anti-patterns
- 把 LoD 當「禁止任何鏈式呼叫」：Fluent API / builder 的
x.a().b().c()回傳的是同一個物件或值，不是穿透別人內部結構——那不違反 LoD。要看的是「有沒有依賴陌生物件的內部」。 - 狂加轉發方法（middle man）：為了不違反 LoD，在每一層都補一個只做
inner.x()的轉手方法，結果是一堆貧血委派。這時該問是不是職責切錯了。 - 誤成 God Object：把所有協作都塞進一個「窗口物件」讓大家只跟它說話，反而養出一個無所不知的上帝類別。窗口要收斂依賴，不是收攏全部職責。
🔑 Takeaways
- 只跟直接朋友說話：不依賴陌生物件的內部結構，真要呼叫就透過第三者轉發。
- 兩個手段：降低成員可見度 + 強調鬆耦合；資訊隱藏 → 促進複用。
- 與 DIP（面向介面）、Mediator（星形協調）、Facade（單一窗口）同一家族；但別為守法則而養出 middle man 或 God Object。
No notes yet — jot your takeaways or Q&A here.