理解程式設計中的「派發（Dispatch）」

更新日期： 2025 年 4 月 19 日

flowchart LR
    A[指令] --> B[派發中心]
    B --> C[執行者1]
    B --> D[執行者2]
    B --> E[執行者3]
    
    style B fill:#ffcc99
    style C fill:#99ff99
    style D fill:#99ff99
    style E fill:#99ff99

在日常生活中，我們時常會遇到「派發」的情境——警察局派遣警員處理事故、物流中心派車送貨、學校派任老師處理某項任務。

這些場景的共通點是：接收到一個「請求」後，系統會選擇一個適當的處理者來「執行任務」。

在電腦科學中，這個動作就叫做「派發（dispatch）」。

什麼是 Dispatch？從「任務分派」的角度理解

概念定義：程式設計中的「派任系統」

在程式設計中，dispatch（派發）是一種「任務分派」的行為，指的是：

系統根據收到的輸入（例如一個事件、一個動作、一個函式名稱、一筆資料），自動決定要執行哪一段對應的程式邏輯，並交由正確的處理者去執行。

這個處理者可能是：

• 一個函式（function）
• 一個方法（method）
• 一段邏輯判斷（如 switch）
• 或甚至是某個 class 或物件的方法

簡單來說：dispatch 就是「收到任務 → 判斷條件 → 派給對的人做」的過程。

🧾 更具體地說：

當你在程式中執行 dispatch 的動作，其實你在做兩件事：

1. 辨認：「這個請求是什麼類型的任務？」
2. 指派：「我應該把它交給哪段程式處理？」

這個過程可以是你自己明確寫死的條件邏輯（像 if 或 switch），也可以是程式語言內建幫你完成的（像是物件導向的動態多型、事件系統等）。

日常生活比喻：叫外送

為了更好理解，我們來看一個生活化的例子：

☎️ 情境：你打電話叫外送

1. 你告訴客服：「我要一份牛肉飯，送到中山北路 XX 號。」
2. 客服不會自己送餐，而是把這筆訂單「派發」給最近的外送員。
3. 外送員接到任務 → 拿到餐點 → 騎車送到你家 → 任務完成！

你會發現：

• 你不用知道是哪一個外送員送的（你只提供請求）
• 客服系統會「根據條件自動決定」誰該處理
• 整個流程是根據規則自動化完成的

這整個「從接單 → 找人 → 執行 → 結束」的過程，就是一個完整的 dispatch。

對照到程式中的情境：

在程式設計裡也是一樣的邏輯。

假設你點了按鈕 Submit，瀏覽器收到這個「點擊事件」後：

1. 系統會判斷這是什麼事件（click）。
2. 系統會找到事先綁定的處理函式（例如 handleClick()）。
3. 執行對應的邏輯（例如送出表單、顯示訊息）。

你不需要管 click 背後到底綁了多少邏輯、事件處理器是誰寫的，只要「派出去」這個事件，程式就會幫你完成整個分派與執行的流程。

程式設計中的 Dispatch 是怎麼用的？

在了解什麼是 dispatch（任務派發）之後，接下來我們要來看看它，實際在程式設計中是怎麼被使用的。

dispatch 的使用方式根據語言特性與架構設計，會有不同形式的表現。

但基本上可以概括為以下兩種主要形式：

• 函式派發（Function Dispatch）
• 方法派發（Method Dispatch）

函式派發（Function Dispatch）

📌 概念說明

函式派發是指：你根據某個輸入條件（通常是字串、數字或類型），選擇一段對應的邏輯來執行。

這種派發方式是由開發者自己寫邏輯來處理的，例如使用 if...else 或 switch...case 來比對條件，再手動呼叫對應的函式或操作。

💡 使用場景

• 根據按鈕類型決定執行行為
• 根據後端 API 傳來的事件字串，呼叫不同處理函式
• 實作自定義命令列工具（CLI）

👉 範例：JavaScript 中的 switch-case 派發

function handleEvent(type) {
  switch (type) {
    case 'click':
      console.log('點擊事件');
      break;
    case 'hover':
      console.log('滑過事件');
      break;
    case 'keydown':
      console.log('鍵盤事件');
      break;
    default:
      console.log('未知事件');
  }
}

handleEvent('click');   // 輸出：點擊事件
handleEvent('hover');   // 輸出：滑過事件

這裡的 handleEvent(type) 就是一個「派發中心」，根據傳入的 type，執行對應的邏輯。這是一種非常直觀的 dispatch 寫法。

🧠 更進一步：改寫成函式表對應

你也可以使用物件或 Map 來進行更乾淨的派發：

const handlers = {
  click: () => console.log('點擊事件'),
  hover: () => console.log('滑過事件'),
  keydown: () => console.log('鍵盤事件')
};

function handleEvent(type) {
  const fn = handlers[type] || (() => console.log('未知事件'));
  fn();
}

handleEvent('click');   // 輸出：點擊事件

這樣可以避免冗長的 switch-case，也方便未來擴充與模組化。

方法派發（Method Dispatch）

📌 概念說明

在物件導向語言中，如 Java、Python、C++ 等，「方法派發」則更加進階。

它會根據「物件的實際類型」來自動決定該呼叫哪個方法。這種行為通常稱為：

動態派發（Dynamic Dispatch）

也就是：在執行階段，根據物件的實際類別，呼叫對應的覆寫方法。

💡 使用場景

• 多型（polymorphism）
• 基礎類別定義統一介面，子類別提供具體行為
• 不同物件共享相同方法名稱，但表現不同

👉 範例：Python 中的多型派發

class Animal:
    def speak(self):
        print("Some sound")

class Dog(Animal):
    def speak(self):
        print("Woof!")

class Cat(Animal):
    def speak(self):
        print("Meow!")

def make_sound(animal: Animal):
    animal.speak()

make_sound(Dog())  # 輸出：Woof!
make_sound(Cat())  # 輸出：Meow!

這段程式碼裡，我們寫了一個函式 make_sound(animal)，它的參數宣告是 Animal 類別，也就是說：

def make_sound(animal: Animal):
    animal.speak()

這樣看起來好像只能處理 Animal 類別的物件對吧？但其實我們傳進去的是：

make_sound(Dog())  # 傳入一隻狗
make_sound(Cat())  # 傳入一隻貓

也就是說，我們不是傳入「一般的動物」Animal，而是傳入「具體的動物」Dog 或 Cat 的實例。

但神奇的是：

animal.speak()

這行程式碼看起來只是呼叫 Animal 的 speak() 方法，但實際上，Python 會自動判斷：

➡️「你傳進來的是一隻狗，那我就執行 Dog 的 speak()」
➡️「你傳進來的是一隻貓，那我就執行 Cat 的 speak()」

這種行為就叫做：

動態派發（Dynamic Dispatch）——根據物件在執行當下的「真實類型」來決定要呼叫哪個方法。

🔍 你可能會好奇的點：

❓ 為什麼程式能知道要叫 Dog 的方法？

因為 Python 是物件導向語言，它在執行 animal.speak() 時，不只會看參數的「表面類型」（也就是 Animal），而是會追蹤這個物件實際是哪個類別產生的（Dog or Cat），再呼叫對應的方法。

❓ 這和 if 判斷差在哪？

• if 是你手動寫邏輯來決定怎麼派發任務。
• 動態派發則是語言內建幫你自動做判斷與呼叫，你只要定義好繼承關係與方法覆寫即可。

函式派發 vs 方法派發 比較表

常見的派發類型（Types of Dispatch）

在程式語言中，派發（dispatch）機制的核心目標是根據你提供的輸入（像是物件的類型、函式參數、事件等），來決定要執行哪一段對應的邏輯。

不同語言、不同應用場景會使用不同的派發策略。以下是最常見的三種類型：

靜態派發（Static Dispatch）

🧠 什麼是靜態派發？

靜態派發的意思是：

在「編譯階段」（也就是你還沒執行程式之前），編譯器就已經決定好了要呼叫哪一個方法或函式。

也就是說，派發的邏輯在程式還沒跑之前就已經定好了，不會根據執行時的資料而改變。

📌 常見於的特性或語言：

• 函式多載（Function Overloading）
• 泛型（Generics）
• C++、Rust、Go 等靜態型別語言

💡 範例：C++ 的函式多載

void print(int x) {
  std::cout << "整數：" << x << std::endl;
}

void print(double x) {
  std::cout << "浮點數：" << x << std::endl;
}

print(10);     // 編譯時期就決定用 print(int)
print(3.14);   // 編譯時期就決定用 print(double)

這裡的 print() 方法在編譯時就根據參數的型別決定使用哪一個版本。

即使程式還沒執行，編譯器就知道怎麼派發。

📦 優點：

• 效能好：不需要執行時再做判斷
• 編譯時檢查更安全

⚠️ 缺點：

• 缺乏彈性，無法根據執行時物件的動態行為做改變

動態派發（Dynamic Dispatch）

🧠 什麼是動態派發？

動態派發是指：

在「執行階段」，根據物件的實際類型來決定要呼叫哪個方法。

這是物件導向程式設計的核心功能，讓你可以在程式運行時再決定要執行哪段邏輯。

📌 常見於的語言與技術：

• Java、Python、C#、TypeScript 等支援類別與繼承的語言
• Java 的虛擬方法表（vtable）機制
• Python 的多型方法呼叫（duck typing）

💡 範例：Java 的動態派發

class Animal {
  void speak() {
    System.out.println("Some sound");
  }
}

class Dog extends Animal {
  void speak() {
    System.out.println("Woof!");
  }
}

Animal a = new Dog();  // 父類型變數指向子類型
a.speak();  // 執行時才決定呼叫 Dog 的 speak()

雖然變數 a 宣告為 Animal，但實際指向的是 Dog 物件，因此在執行時會呼叫 Dog 的 speak() 方法，這就是動態派發的行為。

📦 優點：

• 高彈性：可根據物件的實際類型執行不同邏輯
• 允許抽象設計（例如父類別定義接口，子類別實作細節）

⚠️ 缺點：

• 相較靜態派發，效能略差（需執行時決策）
• 無法在編譯階段完全檢查執行邏輯

多重派發（Multiple Dispatch）

🧠 什麼是多重派發？

多重派發是指：

在執行時，根據多個參數的實際型別，共同決定要呼叫哪一個方法。

與單一派發（只根據呼叫物件本身的類型）不同，多重派發會綜合考慮多個參數的類型組合，才能決定最適合的處理方式。

📌 常見於的語言與架構：

• Julia（內建支援多重派發）
• Clojure（支援 multimethods）
• Python（透過 functools.singledispatch / multipledispatch 模組模擬）

💡 範例：Julia 中的多重派發

function interact(a::Dog, b::Cat)
  println("Dog 與 Cat 相遇，互相嗅聞")
end

function interact(a::Cat, b::Dog)
  println("Cat 遇到 Dog，拔腿就跑")
end

interact(Dog(), Cat())  # 呼叫第 1 個方法
interact(Cat(), Dog())  # 呼叫第 2 個方法

在這個例子中，interact() 的行為不只依賴單一參數，而是根據兩個參數的型別來選擇對應的邏輯，這就是多重派發。

📦 優點：

• 精準控制邏輯，特別適合處理複雜類型組合的情境
• 程式碼清晰易讀，避免巢狀 if 判斷

⚠️ 缺點：

• 複雜度高，需要語言本身支援或額外實作
• 較不常見，新手容易混淆

三種派發方式總整理

不同派發類型適用於不同的設計風格與語言特性：

• 若你追求效能與型別安全，靜態派發會是首選。
• 若你想要設計具有彈性與可擴展性的系統，動態派發是物件導向的靈魂。
• 若你的邏輯依賴於「多個參數」的型別互動，多重派發會讓你的程式更乾淨、更可讀。

當然可以！我會把這段「dispatch 是一種中介行為」的內容，用更簡單的比喻、清楚的角色分工，重新整理一次，讓你不用程式底子也能理解它的設計用意。

dispatch 是一種「中介者」角色

在某些系統架構裡，dispatch 並不是「主動做事的人」，而是扮演一個像是「任務轉接員」的角色。

換個角度想：你是前台，dispatch 是櫃台

想像你走進一間公司，對前台說：

「我有一份申請表單要交。」

這個前台人員不會自己幫你審核、批准或輸出報表。

他的工作是：

✅ 接收你的申請 → ✅ 看表單內容 → ✅ 把表單交給負責的部門去處理。

這就是 dispatch 的本質：

它不做決策，只負責把任務「轉交」給該處理的人。

應用在程式設計上是什麼意思？

在像 Redux 這樣的系統中，前端某個畫面可能發生了一件事（例如：點擊按鈕），你想「加一」一個數字狀態。

你不會直接去修改那個狀態，而是：

dispatch({ type: 'INCREMENT' });

這行的意思是：「我通知系統『有人要加一』，請去處理。」

但處理加一這件事的邏輯，不在你這，而是在 reducer 那邊。

➡️ dispatch 的工作就像那個前台，把這個「加一的請求」轉送到對的地方去處理。

為什麼要這樣設計？不能直接呼叫函式嗎？

可以，但當程式越來越複雜時，你會發現這樣的好處：

✅ 不同功能之間「不會綁死在一起」

// 傳統做法（寫死）：
function handleClick() {
  updateCount();
  logToAnalytics();
  updateUI();
}

上面這樣的寫法會導致所有行為都塞在一起，不好管理、不好測試、不好擴充。

✅ 用 dispatch 的做法：

dispatch({ type: 'SUBMIT_FORM', payload: { name: 'John' } });

這行只負責「送出表單」這個行為的請求，至於：

• 要不要驗證資料？
• 要不要送出 API？
• 要不要顯示 loading？
• 要不要通知別的元件？

通通可以由其他元件、middleware、reducer 自己決定該怎麼處理。

➡️ 你把「決策權」交給系統的其他單位，讓每個功能各司其職。

真實範例

🧪 Redux 中的 dispatch

dispatch({ type: 'INCREMENT' });

這一行的角色分工是：

🧪 EventBus 中的 dispatch

eventBus.emit('user-logged-in', userData);

這一行代表：「我通知整個系統，某人已經登入了，大家可以準備要做自己的事了！」

會有很多監聽器（listener）註冊了 user-logged-in 這個事件，像是：

• A 元件：跳出歡迎訊息
• B 元件：載入使用者資料
• C 元件：寫入瀏覽紀錄

你不需要一個一個叫它們，你只需要「broadcast（廣播）」這件事，其他模組各自處理自己關心的部份。

這種設計帶來的 4 大好處

dispatch 不做事，只送件。誰要處理、怎麼處理，那是別人的工作。

這種「我只送出任務，不管怎麼處理」的做法，就是一種「中介者模式」，讓程式架構更清晰、鬆耦合、更好維護。

結語

雖然「dispatch」這個詞聽起來有點抽象，但其實它貫穿了許多程式架構與程式語言的設計理念。

從最簡單的 switch-case、物件導向方法選擇，到現代框架的事件處理與狀態更新，都離不開它的影子。

了解 dispatch，不只是讓你會「寫程式」，更能幫助你理解系統如何根據輸入做出回應——這正是寫程式最核心的本質之一。