C# 中的 DRY 原則：為什麼程式碼重複會損害您的程式碼庫 - 由 Derek Comartin 解釋

當我們談論在C#中撰寫可維護的程式碼時，一個經常出現的基本概念就是DRY原則 — 勿重複自己。 這是軟體開發的一個支柱，旨在消除冗餘，減少程式碼重複，並且改善程式碼的可維護性。

但就像許多設計原則一樣，DRY可能被誤解甚至誤用。 在他的影片"DRY principle is why your codebase sucks?"中，來自CodeOpinion.com的Derek Comartin提供了一個坦率且務實的觀點，探討了DRY原則應該和不應該如何使用 — 特別是在開發.NET Core或類似的生態系統時。

在本文中，我們將深入了解Derek的解釋，並通過影片中的範例和評論來指導。 無論您是在Visual Studio中啟動一個新專案，維護現有的程式碼，還是僅僅為了更好的程式碼重用性而重構，Derek的見解都是實用且相關的。

DRY 原則的定義

在影片的開始，Derek描繪了許多開發人員面臨的情境：面對一個難以修改的系統 — 一個由重複程式碼和冗餘邏輯組成的糾結混亂。

他將C#中的DRY原則介紹為一種減少程式碼重複的策略，但警告這往往會被誤解。 如Derek在0:28解釋到：

"當DRY被成功應用時，對系統中任何單一元素的修改都不需要更改任何邏輯上無關的元素。"

這一區別非常重要。 DRY原則的目標不僅是避免重複的程式碼，而是促進關注點分離和正確的程式碼重用 — 這樣會導致可維護且乾淨的程式碼，可以更容易地測試和重構。

實際範例：距離轉換

為了讓事情變得具體，Derek提供了一個簡單的C#範例。 他撰寫了兩個方法：

• ShipDistance

• TollDistance

每個都計算出英里距離，然後轉換為公里 — 在這兩個方法中使用了相同的邏輯。 這是典型的程式碼重複。

與其在多個地方使用相同的程式碼，Derek展示瞭如何將轉換邏輯提取到一個私有方法中 — MilesToKilometers() — 這是一種基本但有效的程式碼重構和重用方法。

他用典型的控制台應用程式結構示範：一個包含靜態void Main的Program類。 這是許多開發人員在測試邏輯或嘗試新的使用者輸入場景時使用的結構，例如public int age、string username、string password等。

DRY與過度耦合

雖然將邏輯抽象為可重用的方法或單獨的類聽起來很理想，但Derek提醒要小心。 過度使用DRY，特別是在整個應用程式中，可能會導致危險程度的耦合。

例如，如果您將轉換邏輯放入多個專案共享的實用工具中，稍後更改其舍入行為或小數精度，將不可預測地影響多個區域。 如Derek在2:31所說：

"客戶預期是兩個小數位嗎？ 如果我們更改為零會怎麼樣？"

這是共通關注點 — 被系統多個部分重複使用的邏輯 — 其顯示了過早或沒有明確界限的集中化的風險。

Derek在此的建議反映了單一職責原則和依賴反轉原則，這是保持程式碼適應性和模組化的兩項重要SOLID原則。

DRY失誤造成的程式碼膨脹

DRY誤用的另一個問題是程式碼膨脹 — 企圖讓所有事物抽象化會導致膨脹的實用類或過於通用的方法。 Derek警告說，過度乾燥化邏輯可能會導致傷害大於幫助，特別是在大型系統中，因為一個區域的bug修復可能會因為共享依賴而影響其他區域。

根據Derek，關鍵在於知道不共享程式碼的時機 — 特別是如果它導致緊密耦合的模組。 DRY不是規則； 它是一種需要具體情境使用的指導方針。

DRY應用於實體：複雜度的配方

Derek指出常見的開發人員傾向：圍繞卡車、訂單、司機、和貨物等實體來組織系統。 雖然很有誘惑力想在不同的方法中重用相同的類或物件，但這往往會導致概念重複和不需要的耦合。

他認為業務能力 — 不僅僅是資料結構 — 應該驅動架構的設計。 例如，"派送訂單"是一個不同於"解勾拖車"的關注，即使它們涉及相同的實體。

在4:45，Derek解釋：

"您系統中的單一實體不必是多個概念的表現。"

這突顯了更深層次的架構見解：同名的實體（車輛、拖車）可能在不同的工作流程中表示不同的責任。 將它們互換使用會導致混淆並緊密地將不相關的業務邏輯耦合在一起。

DRY和業務能力

為了解決這個問題，Derek引入了垂直切片架構（VSA）— 一種圍繞業務能力而非層的應用程式結構模式。 "每個"切片"包括特定動作或使用案例所需的一切 — 從請求到資料庫 — 封裝且自包含。

他強調在一個切片內的DRY程式碼是好的 — 在單一位置內 — 但在切片之間應用DRY會導致糾纏的依賴。 在6:44，他補充說：

"這只是關於減少耦合，增加內聚力…… 和這樣做的一個方法是：不要在界限內重複概念。"

這種基於界限的思維給予您靈活性。 您可能有一個完整的領域模型在一個切片中，而只是在另一個切片中有一個輕量資料模型。 這取決於切片的需求 — 一種與《實用程式開發者》哲學一致的實用方法。

最後的想法

Derek以重新將DRY視為一種工具而非法律來結束。 如他所說，在7:00：

"這只是關於理解您如何應用它。 如果您大量應用它，可能會有更多的耦合。"

因此，在提取那段驗證邏輯、連接字串或將重複的程式碼轉變成一個單獨的方法之前，考慮這樣做是否真的會讓您的整個程式碼基更容易維護 — 還是更難以更改。

結論

Derek Comartin對C#中DRY原則的剖析顯示了當不加考慮地應用時，一條看似簡單的規則怎麼可能適得其反。 通過走過程式碼範例，討論實際情境，並強調軟體設計原則，他揭示了重用性和模組化之間所需的平衡。

為了顯著提升您的開發過程，請記得：

• 在明確的界限內使用DRY重構冗餘程式碼。

• 不要將服務於不同業務目的的實體乾燥化。

• 當集中邏輯時請尊重情境 — 特別是跨多個地方或專案時。

• 考慮單元測試以及相依性注入可能如何影響共享程式碼。

通過應用這些教訓，您將撰寫出更有效率、更具模組性和更易於維護的C#程式碼 — 並且避免將您的程式碼基轉變成由重複邏輯和糾結依賴組成的亂局。

您可以觀看Derek Martin完整的影片以獲得更多CodeOpinion的YouTube頻道上的見解。