C#接口為鬆耦合服務 — 通過Tim Corey的第16課解釋

連接表單很容易—正確連接它們並不容易

在1:18，Tim 開始連接建立獎品和建立團隊的 UI 元素。 他立即指出，這一步可能會令人感到困難，不是因為呼叫另一個表單很難，而是因為正確獲取資料才是人們通常會犯錯的地方。

Tim 解釋挑戰不在於打開另一個表單—這部分很簡單。 挑戰在於一個表單如何在不產生長期設計問題的情況下與另一個表單進行通信。 這就是定義契約而非依賴性的重要性開始顯現的地方。

緊耦合的誘惑

在1:34，Tim 明確指出一個常見的錯誤：直接將建立比賽表單與建立獎品表單緊密連接。 在這種方法下，一個類確切知道它正在與哪個其他類進行交談。

Tim 解釋說，這樣會產生緊密耦合，意味著表單直接依賴彼此。 如果一個表單改變，另一個就會受到影響。 如果程式的另一部分以後需要相同的功能，它無法重用它。

他強調，儘管這樣做可能會編譯和運行，但它並不是長期的好設計選擇，特別是在較大的系統或專業環境中。

在編寫程式碼之前思考步驟

在2:02，Tim 停下來寫出步驟而不是直接進入程式碼。 他列出了：

1. 呼叫建立獎品表單

2. 返回 PrizeModel

3. 新增到選定獎品列表

Tim 解釋說，首先寫下步驟有助於避免邏輯錯誤並使程式碼意圖清晰。 這種結構化的思考在引入接口後變得尤為重要，因為介面定義了必須發生的內容，而不是如何發生。

引用型別及為什麼返回值並不總是需要

在4:56，Tim 解釋了一個重要的細節，即模型被傳遞。 他提醒觀眾，他們在傳遞地址，而不是物件的副本。

當通過資料連接器保存獎品時，該模型已經填充了其 ID。 Tim 指出，通常不需要再次返回該模型，因為實例已經被修改。

這進一步證明了介面並不是為了盲目移動資料而存在的—它們存在是為了信號完成和責任，而不是重複。

為什麼首先傳遞模型是個壞主意

在6:42，Tim 討論了將 PrizeModel 傳遞到表單構造函式中的想法，從而兩個表單共享相同的實例。

他解釋了為什麼這在實際使用中失敗：如果使用者取消表單，您的列表中會有一個空的或無效的獎品。Tim 展示了僅僅因為兩個類可以共享實例資料並不意味著它們應該這樣做。

這一刻強調了介面是定義行為，而不是資料儲存。

直接傳遞呼叫表單更糟

在7:46，Tim 描述了另一種常見的方法：將整個建立比賽表單傳遞到建立獎品表單，並調用一個名為 SavePrize 的公共方法。

Tim 解釋為什麼這更糟：

• 獎品表單現在知道是哪些類正在呼叫它

• 沒有其他無關類可以重用該獎品表單

• 該類被鎖定在單一用例中

他明確將其命名為緊耦合，這正是我們試圖避免的。

引入介面作為契約

在9:01，Tim 說明了解決方案：介面。

他使用接口關鍵字建立了一個新介面並將其命名為 IPrizeRequester。 Tim 提醒觀眾，介面：

• 不是一個類

• 不包含具體方法

• 存在於定義契約

介面包含一個方法：

• PrizeComplete(PrizeModel model)

Tim 解釋，該方法定義了必須發生的事情，而不是它如何發生。

介面成員和責任

在9:40，Tim 解釋，誰實現這個接口，誰就同意支持該方法。 介面預設擁有公共成員，並且不聲明實例資料。

這是 Tim 清楚說明介面定義了能力，而不是儲存的地方。 實現類決定在調用方法時該做什麼。

傳遞介面型別而不是類

在10:19，Tim 修改了建立獎品表單構造函式以接受 IPrizeRequester 而不是具體的表單。

他解釋這意味著：

• 有人會呼叫該表單

• 該表單不知道那是誰

• 唯一的要求是呼叫者實現介面

這是實踐中的鬆散耦合。獎品表單依賴於介面型別，而不是具體的類。

將介面實例儲存以供以後使用

在11:06，Tim 將介面實例儲存在類別中。 他解釋，除非在構造函式中儲存，否則構造函式參數只存在於構造函式內。

這使得獎品表單能夠在按鈕點擊事件中稍後調用 PrizeComplete。

回調實現類

在11:49，Tim 顯示了關鍵時刻：

callingForm.PrizeComplete(model);

他解釋，獎品表單現在回調到誰實現了介面，並表示：

"我已完成，這是完成的模型。"

這次調用之後表單才會關閉。 這保證了獎品只有在建立成功時才會被新增。

在比賽表單中實施介面

在13:29，Tim 轉到建立比賽表單並實施介面。

他在13:58解釋了 this 關鍵字，將其描述為當前實例—儲存在記憶中的實際物件。 通過傳遞 this，該表單正在交出其地址，但僅通過介面契約。

多個介面，一個類

在18:41，Tim 介紹了第二個介面：ITeamRequester。

他解釋了儘管一個類只能繼承一個基類（例如表單），但它可以實作多個介面。 這允許單個類支援多個不相關的行為而不需要多重繼承。

Tim 強調，介面不會引入程式碼——它們僅定義必須的方法。

模式、一致性和錯誤檢測

在42:08附近，Tim 反思為什麼使用模式是有意義的。 重複相同的基於介面的結構使得缺少的步驟明顯並且更容易除錯。

Tim 鼓勵寫下事情，使用一致的模式，而不是試圖把一切保存在腦海中。 在他看來，好的設計不在於完美——而是在於清晰、結構和使將來變更更加容易。

結論

在第16節課中，Tim Corey 使用了一個真實的 WinForms 使用案例來展示介面如何實現鬆散耦合。 他不依賴於抽象的範例，而是展示了介面如何：

• 定義契約

• 設置類的解耦

• 支援在單個類中多個介面

• 防止緊耦合

• 提高長期的靈活性

到課程結束時，應用程式不僅能運行——而是結構化地支援增長、重用和清晰。 Tim 的方法讓介面在真實世界的 C# 開發中顯得實用、有目的和至關重要。

欲了解這些接口和鬆散耦合概念的完整、端對端應用，請觀看完整的第16節影片，其中每一步都在工作中的 C# 應用中實施、測試和改進。