設計模式入門：中介者模式 Mediator Pattern
閱讀時間約 1 分鐘
在開發大型系統時，常常會發現各個物件之間的溝通愈來愈複雜，像是編織成了一張複雜的蜘蛛網。每個物件相互依賴，任何改動都可能牽一髮而動全身。這時候中介者模式就能幫助我們化繁為簡，成為一個「協調者」，讓物件之間的溝通變得簡單清晰。
什麼是中介者模式？
中介者模式是一種行為型設計模式，它讓物件之間的溝通透過一個中介者來進行，從而減少彼此的直接依賴。想像你在一家公司工作，當你需要和不同部門溝通時，不必一個個去找各部門的人，而是透過人資部門（HR）來協調。HR 就是中介者，負責傳遞訊息，讓各部門之間的溝通變得更高效且有條理。
中介者模式的應用：聊天室
一個典型的例子就是聊天室。在聊天室裡沒有中介者的話，每個使用者都必須知道其他所有使用者，才能互相發送訊息，這會讓系統變得非常複雜。但透過中介者模式，使用者只需和中介者溝通，而中介者負責將訊息傳遞給其他使用者。這樣一來，無論聊天室裡有多少人，使用者之間都不需要直接交互，大大簡化了系統的結構設計。
中介者模式的優點與缺點
中介者模式的最大優勢是「解耦」，物件不再需要彼此依賴，這讓系統結構更加清晰，便於維護和擴展。然而隨著系統變大，中介者本身可能會變得非常複雜，成為一個臃腫的「神經中樞」。所以在使用中介者模式時，我們也需要小心控制中介者的複雜度。
總結一下，中介者模式非常適合在需要協調多個物件互動的場景中使用，像是聊天室、事件通知系統等。透過中介者模式我們可以有效地減少物件間的依賴關係，讓系統更靈活。但同時也需要注意不要讓中介者變得過於複雜。
想透過實際範例來理解設計模式，可以參考我今年在iThome鐵人賽上發表的文章。
https://ithelp.ithome.com.tw/articles/10348742
6會員
83內容數
對於經營自媒體、部落格或社群媒體感興趣？我專注於提供實用的寫作技巧、數位行銷策略，以及個人成長建議。
每週，我會分享提升寫作技巧、優化部落格經營、有效管理社群媒體、以及投資理財的寶貴知識。追蹤我，獲得實用的工具和建議，讓你的個人品牌和財務管理更上一層樓！
留言0
查看全部
你可能也想看
Google News 追蹤
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
Hi 大家好，我是Ethan😊
相近大家都知道保濕是皮膚保養中最基本，也是最重要的一步。無論是在畫室裡長時間對著畫布，還是在旅途中面對各種氣候變化，保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水，還能提升後續保養品的吸收效率。
曾經，我的保養程序簡單到只包括清潔和隨意上乳液
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
※ 什麼是Middleware (中介層)？
Middleware 一般翻譯作「中間件」或是「中介軟體」，其實 Express 應用程式就是由一連串的 middleware 串連而成：
從 request 進來到 response 回去會經過一系列的流程。
這個流程會按照路由清單由上而下執行。
※ 生產者和消費者模式
定義：
生產者和消費者在同一時間內共同存取某一個資料空間。生產者負責生成數據並將其放入共享空間，消費者負責從共享空間中取走數據進行處理。兩者之間互不相干，也不須互相知道對方的存在。
共同存取資料空間：生產者和消費者共享同一個資料空間。這個空間通常是緩衝區或隊列，用於在它
※ 觀察者模式
定義：
觀察者模式（Observer Pattern）是一種設計模式，涉及兩個主要角色：觀察者（Observers）和被觀察者（Subject）。在這種模式中，一群觀察者訂閱並觀察某個被觀察的對象。當被觀察者的狀態發生改變時，它會通知所有觀察者，讓他們知曉並作出相應的反應。這種模
※ 工廠模式
定義：
工廠模式是一種實現了「工廠」概念的物件導向設計模式。它提供一個通用的工廠介面，將創建instance（實例）的程式碼交由子類別各自實現，並根據需求去動態地生成相應的物件。這種模式將物件的創建邏輯與使用邏輯分開，使程式碼更容易維護和擴展。
特點：
具有高度標準化和同質性的
※ 單例模式介紹
※ 定義：單例模式是一種設計模式，確保一個class（類）只有一個實例，並提供一個存取它的全域存取點。無論如何取值，皆只對這個實例取值。
※ 目的：保證一個類別只會產生一個物件，而且提供存取該物件的統一方法。
※ 講解：單例模式確保一個類無論怎麼 new 或 get，都只能拿
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
上一篇文章提到有些介面不應被繼承，但物件導向的子類別只能繼承父類別的介面，因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制，這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承，更適合使用組合，根本不需要使用繼承疊加特性。
資料類型的定義往往跟怎麼建構模型相
類似於trait/typeclass的特性系統能提供程式「延展性」，它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像，然而特性系統的彈性比較大一點，而且概念上也有一些差別。為了探討討論這些差異，我們必須深入了解繼承機制到底是什麼。
繼承並不是建立子類關係的唯一方法。所謂的
這個秋，Chill 嗨嗨！穿搭美美去賞楓，裝備款款去露營⋯⋯你的秋天怎麼過？秋日 To Do List 等你分享！
秋季全站徵文，我們準備了五個創作主題，參賽還有機會獲得「火烤兩用鍋」，一起來看看如何參加吧～
11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
Hi 大家好，我是Ethan😊
相近大家都知道保濕是皮膚保養中最基本，也是最重要的一步。無論是在畫室裡長時間對著畫布，還是在旅途中面對各種氣候變化，保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水，還能提升後續保養品的吸收效率。
曾經，我的保養程序簡單到只包括清潔和隨意上乳液
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
※ 什麼是Middleware (中介層)？
Middleware 一般翻譯作「中間件」或是「中介軟體」，其實 Express 應用程式就是由一連串的 middleware 串連而成：
從 request 進來到 response 回去會經過一系列的流程。
這個流程會按照路由清單由上而下執行。
※ 生產者和消費者模式
定義：
生產者和消費者在同一時間內共同存取某一個資料空間。生產者負責生成數據並將其放入共享空間，消費者負責從共享空間中取走數據進行處理。兩者之間互不相干，也不須互相知道對方的存在。
共同存取資料空間：生產者和消費者共享同一個資料空間。這個空間通常是緩衝區或隊列，用於在它
※ 觀察者模式
定義：
觀察者模式（Observer Pattern）是一種設計模式，涉及兩個主要角色：觀察者（Observers）和被觀察者（Subject）。在這種模式中，一群觀察者訂閱並觀察某個被觀察的對象。當被觀察者的狀態發生改變時，它會通知所有觀察者，讓他們知曉並作出相應的反應。這種模
※ 工廠模式
定義：
工廠模式是一種實現了「工廠」概念的物件導向設計模式。它提供一個通用的工廠介面，將創建instance（實例）的程式碼交由子類別各自實現，並根據需求去動態地生成相應的物件。這種模式將物件的創建邏輯與使用邏輯分開，使程式碼更容易維護和擴展。
特點：
具有高度標準化和同質性的
※ 單例模式介紹
※ 定義：單例模式是一種設計模式，確保一個class（類）只有一個實例，並提供一個存取它的全域存取點。無論如何取值，皆只對這個實例取值。
※ 目的：保證一個類別只會產生一個物件，而且提供存取該物件的統一方法。
※ 講解：單例模式確保一個類無論怎麼 new 或 get，都只能拿
讓我在這篇文章總結一下前面對物件導向設計的討論，我們討論了物件導向的四個特性：繼承、抽象、多型、封裝，分析了它們的問題，並跟函數式編程的思維做比較。我們引入了與之相對應的特性：泛型、特性系統、模組化，有些特性雖然跟那四個特性很像，但在一些細微的地方有不同的詮釋，使得整體思考方式很不一樣。
「繼
物件導向設計的一個重點就是封裝，這有很多層面上的意義，但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關，這使得有一些時候我們逼不得已必須把函式定義在類別上，這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責，並不需要再給物件相同的能力。
一般的模組系統就是把相
上一篇文章提到有些介面不應被繼承，但物件導向的子類別只能繼承父類別的介面，因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制，這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承，更適合使用組合，根本不需要使用繼承疊加特性。
資料類型的定義往往跟怎麼建構模型相
類似於trait/typeclass的特性系統能提供程式「延展性」，它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像，然而特性系統的彈性比較大一點，而且概念上也有一些差別。為了探討討論這些差異，我們必須深入了解繼承機制到底是什麼。
繼承並不是建立子類關係的唯一方法。所謂的