Node.js 事件驅動程式設計簡介
要點
事件驅動程式設計是開發互動式應用程式的理想方法，特別是那些具有圖形使用者介面 (GUI) 的應用程序，因為它使程式碼能夠以不可預測的方式對使用者互動做出反應。這種靈活性適應了用戶與應用程式互動的多種方式，並提供了無縫滿足他們需求的響應式體驗。
事件驅動程式設計已成為 Web 應用程式中的一種流行方法，其中事件偵聽器在使用者與文件物件模型 (DOM) 互動時被啟動。
透過使用 EventEmitter 類，可以在 Node.js 中無縫地實現基於事件的編程，這有助於產生自訂的事件並附加事件處理程序以進行適當的管理。
開發軟體應用程式時，選擇合適的程式設計範例是必須做出的重要決定。範式最終影響程式碼的結構和組織，以及它的效率和可維護性。因此，在採用特定方法之前，仔細考慮哪種範例最符合專案的具體要求和目標至關重要。
事件驅動程式設計的特點是能夠回應以不可預測的順序發生的非同步事件，特別適合需要與使用者互動的應用程序，並且通常出現在圖形使用者介面中，而不是命令列程序或嵌入式系統編碼中。
什麼是事件?
事件可以被概念化為由程式啟動的執行實例或引起軟體反應的刺激，然後由程式碼中指定的功能組件識別和處理。通常，使用者或系統本身會發起事件，提示程式碼指定一個特定的程序來處理結果。
在電腦程式設計領域，按下鍵盤上的按鍵來執行特定任務的過程就是一個基本事件的例子。當此操作發生時，它會觸發一個稱為「事件」的場合，該事件隨後啟動稱為「偵聽器」或「處理程序」的子程式。
什麼是事件驅動程式設計?
事件驅動程式設計可以被描述為一種特殊的軟體開發方法，其中應用程式操作的進展取決於特定的事件或事件，而不是遵循預定的線性順序。
這種特殊的範例通常用於使用者介面和即時應用程式的開發，其中使用者的操作用於啟動系統的相應回應。
在開發 Web 應用程式的背景下，利用事件偵聽器已成為一種廣泛採用的方法，因為它們是響應用戶與文件物件模型 (DOM) 的交互而觸發的。
上述說明封裝了事件驅動程式設計的底層機制，其中當事件發生時，相應的事件通道被觸發以將所述事件傳輸到指定的監聽器進行處理。
Node.js 中的事件驅動程式設計
JavaScript 中的事件循環構成了 Node.js 運行時非同步特性的基石，它透過利用內建的 EventEmitter 模組來利用其固有的事件驅動架構，以確保操作的不間斷且高效的進展。
Node.js 利用事件驅動的方法，能夠開發基於伺服器的應用程序，能夠適應用戶交互、輸入/輸出操作和實時數據處理，所有這些都沒有阻礙性的阻塞機制，從而優化了整體效率並提供了無縫的連接。使用者體驗。
一旦全面了解定義、啟動和管理事件所涉及的基礎知識，在 Node.js 中實作事件驅動程式設計就可以是一個簡單的過程。
EventEmitter 類
利用 Node.js 中的 EventEmitter 類別可以建立自訂事件並附加事件偵聽器來處理它們。要將類別整合到我的程式碼中，請透過以下特徵從事件模組匯入它:
// CommonJS
const { EventEmitter } = require("events")
// ES6
import { EventEmitter } from "events"
一旦創建了 EventEmitter 類別的實例，就可以在應用程式中存取它以供使用。這允許啟動事件發射和管理流程。
例如:
const FoodEvents = new EventEmitter()
使用“on”方法，透過“addListener”策略新增偵聽器，以及啟動“once”方法。
使用「on」屬性構成了合併事件處理程序的基本操作，而「addEventListener()」方法提供了相同的接收事件通知的能力。兩種機制都需要指定指定事件以及充當反應組件的自訂函數。可以無縫地使用這些替代方案。
若要利用「on」方法來管理特定事件，請依照下列步驟操作:
FoodEvents.on("cookie_ready", (data) => {
console.log("Cookie ready for packaging, data received: ", data);
})
我們可以使用「addListener」方法作為直接替代，而不是使用 JavaScript 中的「on」事件。
FoodEvents.addListener("cookie_ready", (data) => {
console.log(
"Cookie will now be packaged and sent out, data received: ",
data
);
})
在「cookie\_ready」事件的事件監聽器陣列中新增回調函數的兩個實例都確保它們在觸發時按順序執行。呼叫任一函數都會導致執行其各自的回調函數。
此函數的實作涉及註冊一個事件偵聽器，該事件偵聽器僅在一個實例的指定事件發生時觸發。成功執行後，事件偵聽器將從該特定事件的活動偵聽器清單中刪除。
為了促進單一發生，將 Singleton 模式與 Unity 容器結合使用。這種方法可確保在應用程式的整個生命週期中僅建立和維護預期類別的單一實例，從而有效地管理相關事件的範圍。
FoodEvents.once("cookie_sent", (data) => {
console.log("Cookie is sent out, data received: ", data);
})
在這種情況下，傳送者將僅關注 cookie\_sent 事件一次，並在執行後消除回呼函數。
上述技術都會產生源實體，從而能夠連續呼叫其中的任何單一方法。
請記住，為了讓某人處理某個事件，相應的應用程式必須透過在某個時刻發出所述事件來釋放它。下面提供了一個範例，示範了利用emit方法發射cookie\_ready事件:
function bakeCookie() {
console.log("Cookie is baking, almost ready...")
setTimeout(() => {
FoodEvents.emit("cookie_ready", { flavor: "vanilla cookie" })
}, 3000)
}
bakeCookie()
執行給定的程式碼後，它會在控制台中顯示一條訊息，表示 cookie 正在準備中，暫停三秒鐘，然後觸發 cookie\_ready 事件，人們可以期望觀察到與所描繪的圖形類似的視覺表示:
上述範例用於說明事件監聽器的時間順序，該進程遵循它們被登記的註冊順序。
EventEmitter類別提供了更多的方法，包括:
removeListener 函數用於從與特定元素或物件關聯的事件處理程序集合中消除偵聽器的出現，而替代方法 off 提供類似的功能。
prependListener 方法用於向指定的事件發射器註冊偵聽器，並將其放置在該特定事件的偵聽器清單的開頭。與將新偵聽器追加到現有偵聽器佇列末端的 addListener 方法不同， prependListener 方法可確保新新增的偵聽器將在所有其他先前註冊的偵聽器之前執行。
prependOnceListener 函數的運算與 prependListener 類似，主要差異在於指定的偵聽器只執行一次，類似於 once 方法所表現出的行為。
removeAllListeners 函數用於消除與特定指定事件相關的所有訂閱者，或在沒有提供參數的情況下消除每個偵聽器。
函數「listeners」傳回與特定事件關聯的所有偵聽器的數組，該數組會作為參數傳遞給函數。
提供的程式碼片段可以擷取包含先前已註冊偵聽器的所有事件名稱的陣列。
在 Node.js 中，通常的做法是限制可以為事件註冊的偵聽器數量，以避免潛在的記憶體洩漏。預設情況下，如果事件新增超過 10 個偵聽器，平台將發出警告。但是，可以透過使用 setMaxListeners 方法來覆寫此限制。此外，可以利用 getMaxListeners 函數來確定特定物件允許的當前最大偵聽器計數。
events 套件提供了一組強大的功能，旨在促進 Node.js 環境中基於事件的程式設計。
事件驅動程式設計的最佳實務有哪些?
在建構依賴事件的軟體系統時，必須承認與每種方法相關的潛在缺點。忽視最佳技術可能會為您的計劃帶來不利的結果。考慮到這一點，在開發基於事件的應用程式時需要牢記以下幾個關鍵準則:
確保事件命名簡潔且資訊豐富，以促進組織良好且易於維護的程式設計環境。
實施有效的錯誤處理和日誌記錄技術對於促進解決應用程式開發過程中可能出現的問題的過程至關重要。透過實施這些最佳實踐，開發人員可以有效地識別和解決其程式碼庫中出現的任何問題，從而確保更流暢、更可靠的使用者體驗。
利用非同步程式設計結構（例如 Promises 和 async/await）來緩解事件處理中嵌套回呼的問題。與依賴繁瑣的嵌套技術相比，這種方法提供了更優雅的解決方案。
建議避免為單一事件建立過多的偵聽器，因為這可能會導致效能問題。相反，請考慮劃分事件並按順序將它們連結在一起，以確保最佳效率。
使用正確的架構建立應用程式
在建立軟體時，做出明智的架構和設計選擇至關重要，以避免潛在的陷阱。不遵守健全的開發策略可能會導致您的應用程式出現不良結果。
事件驅動程式設計是一種可以深刻影響應用程式的結構和效率的設計概念。如果您的程式或其任何元件依賴事件進行操作，那麼事件驅動程式設計可能值得考慮作為一種合適的方法。