指南 - 擴展方法vs部分類

Question

我們在工作中討論定義實體類方法的最佳方式 - 作爲擴展方法或使用部分類。我們討論的方法不會修改實體的狀態，它們純粹是詢問狀態並返回值的「輔助」方法。

這兩種方法的主要優點是保持實體類的清潔，同時仍然爲客戶端代碼提供智能感知支持。

我沒有強烈的偏好，但很想知道其他人是否有偏好（或知道有文件記載的指導原則）朝向某一方。

我開始寫優點爲我能想到的每一種方法的名單，但最後都是我想出來的是：

分部類

• 的方法（即使它是另一個文件），因此Visual Studio工具支持「查找方法」（例如，在resharper中的ALT- \）將找到方法

• 其他文件co ntaining輔助方法只要實體類被打開，由於使用partial關鍵字

擴展方法

• 文件（「entityNameExtension」）和它的下落的命名是顯而易見的在項目中（在「擴展」子文件夾中）是直觀且易於搜索的

其他人可以添加他們的意見嗎？

PS我不認爲這是以下問題的重複，因爲該問題的提問者很滿足於標記將功能差異概括爲正確答案的答覆，該答案不回答關於哪個問題方法是在這種情況下的最佳實踐： Partial Class vs Extension Method

編輯 - 我在尋找人們對一種方法或其他偏好，因爲沒有記錄的指導方針，我們可以找到這種特殊情況。兩種方法都是可能的，既不違反任何設計原則，所以這是一個偏好問題，我想知道你的。

Answer 1

在我看來，擴展方法有兩個好處。首先，當你將它們應用於接口時，它給了你寫一個抽象基類的錯覺，它允許你定義一些常用的方法，但它更靈活，因爲一個類只能有一個基類，但可以實現多個接口。其次，如果你將它用於常規課程，那麼我傾向於將其視爲某種黑客行爲。當原始類缺乏某些方法時，你確實覺得他們應該有這些方法，但他們不這樣做，而且他們不在你的範圍之內，所以你不得不在其他地方實現它們，作爲實用方法，並且它給出了你錯覺它確實存在。

這兩種情況最終都只是語法糖，但擴展接口對我來說更有意義，例如我只看LINQ的Enumerable類。我已經在幾十個完全不同的類上使用了這些擴展方法，所以它確實得到了回報。類擴展方法的一個例子是，在我將它添加到框架之前，我自己創建了string.IsNullOrWhitespace。

擴展接口似乎是正確的，因爲接口定義了一個契約，並且您可以在擴展方法中依賴該契約，但是當您擴展常規類時，它可能會更改並破壞擴展方法。當然，接口也可能會發生變化，但我認爲它們的設計更加徹底，但我沒有任何統計數據。

然後是面向對象編程的情況。你覺得你的方法應該去哪裏，誰使用這些額外的方法，邊界在哪裏。如果你認爲一個方法屬於一個類，然後把它放在課堂上。這很有道理，很簡單。在拓展方法被髮明之前，人們寫出了非常好的課程，他們把所有的東西放在它所屬的地方，生活很好，哈哈。

部分類很酷，因爲它們不像擴展方法那樣大。它們不是語法糖，不是魔法。它只是處理自動生成的類的最好和最簡單的方法，所以我不認爲它太多。我編寫了一些代碼生成器，它們發出的區域可供人類編寫自己的東西，並且在隨後的代碼生成中不會被覆蓋。這樣更舒服，但就是這樣。我無法改變.NET工具如何生成代碼，並且他們不這樣做，所以部分類是最好的。

總結起來，我的意見是，只有在真的必須使用擴展方法時，纔會儘可能地使用部分類。

Answer 2

我不知道爲什麼你會創建一個部分類無論你原來的類已經超出了它的目的。看看你想要擴展的課程，他們真的在做一件事，還是他們在做很多事情。看看單一責任原則（http://en.wikipedia.org/wiki/Single_responsibility_principle）。

如果你可以創建OTHER CLASSES可以利用的方法，我會建議創建一個擴展類。它將擴展其他類的能力，使您的工具箱更加靈活。