用一個中介者集中管理一群物件之間的多對多互動，讓每個同儕只跟中介者說話，而不直接互相引用。網狀耦合因此被收斂成星狀。
🧠 When to Use
TIP
訊號：一堆物件彼此互相引用、誰改了就要通知一票對象，耦合圖糊成一團蜘蛛網，你開始數不清「誰會影響誰」。
- 一組同儕物件互動複雜且彼此直接依賴，難以獨立重用。
- 互動邏輯散落在各物件裡，想集中到一處管理、調整。
- UI 元件協調（一個欄位變動要連動啟用／停用、計算其他欄位）。
⚖️ Structure & Variants
經典版 — 同儕只認得中介者
interface Mediator { fun notify(sender: String, event: String) }
class Dialog : Mediator {
val ok = Button(this); val agree = CheckBox(this)
override fun notify(sender: String, event: String) {
if (sender == "agree") // ← 協調邏輯集中在此
ok.enabled = (event == "checked")
}
}
class Button(private val m: Mediator) { var enabled = false }
class CheckBox(private val m: Mediator) {
fun toggle(checked: Boolean) = m.notify("agree", if (checked) "checked" else "")
}Button與CheckBox互不認識，連動規則只住在Dialog裡。
和 Observer 的關係
- 兩者都在「減少物件間直接引用」；常用 Observer 機制來實作 Mediator（同儕對中介者發事件）。
- 差別：Observer 是單向廣播、發送者不在乎誰收；Mediator 額外集中決策這些訊號之間該怎麼連動。
和 Facade 的差別（最容易混）
- Facade：對一組子系統提供單向、簡化的入口；子系統不會回頭呼叫 facade。
- Mediator：在同儕之間雙向協調；同儕會主動通知中介者、中介者也會回頭驅動同儕。
⚠️ Misuse & Anti-patterns
- 中介者變成上帝物件：所有邏輯都塞進來，它本身變成最難維護的巨類；該拆領域邏輯時別硬留在中介者。
- 只有兩三個物件、互動很單純：直接讓它們互相呼叫更清楚，硬加中介者只是多一層轉手。
- 把耦合藏起來而非減少：同儕還是隱性依賴中介者裡的特定規則，改一條連動就牽動全局——協調邏輯要分得清楚、可測試。
🔑 Takeaways
- 本質是「把網狀的多對多耦合，收斂成以中介者為中心的星狀」。
- 常借 Observer 來傳遞同儕訊號，再由中介者集中決策。
- 別跟 Facade 混淆：facade 單向簡化、mediator 雙向協調；也小心中介者膨脹成上帝物件。
No notes yet — jot your takeaways or Q&A here.