c＃單獨文件中的多個類？

Question

我只是想知道其他人在單個或單獨的.cs文件中關於相關類的想法是什么？

例如，如果我有一個由任意10個其他類實現的接口，你會將它們全部放在同一個文件中還是將它們分開？

謝謝。

Answer 1

我總是為每個班級分別使用單獨的文件。 這是推薦的最佳實踐，它確實很有意義。

Answer 2

我的方法是1個文件== 1個類/接口/模塊/ ...無論如何。 所以文件名總是反映出那里的內容。 對我而言，這是最干凈的方法。

Answer 3

我會將類分成不同的文件。 這使得它們在IDE中更容易找到。

Answer 4

我會將每個類放在一個單獨的文件中，並將接口放在一個單獨的文件中。

我會給該文件以下名稱.cs

這是推薦的最佳做法; 它可以讓你快速找到你的課程。 我總是采用這種方法（除非我有內部課程。））。

Answer 5

我必須同意其余部分：1 class = 1 file。

還要為正確的項目名稱和文件夾使用正確的命名空間。 接口也進入單獨的文件，但我通常將枚舉和結構保存在其他類中。

文件夾可用於將某些類組合在一起。 然而，當你“沒有名字”時可能會出現一個小問題。

例：
解決方案： Tedd.CoolApp
項目： Tedd.CoolApp.Engine
現在我怎么命名這堂課？ 我想把它命名為Engine ，但那會給我Tedd.CoolApp.Engine.Engine ...... :)

Answer 6

計算機可能不太關心你編寫的文件夾結構，所以這個問題肯定屬於代碼可讀性的范疇。 正如本文中提到的關於代碼可讀性標准 ， 友好命名 ， 一致性和邏輯代碼分離是創建可讀代碼的基礎。

那么，這讓我們離開了什么地方？ 文件的創建 - 以及命名空間和文件區域的創建 - 應該是一致的。 這些名字應該是可以理解的。 並且每個聚合類別中的代碼應該有一些共同點，應該在類別名稱中詳細說明。 最后，在可讀性的情況下，您正在考慮您的代碼可能會被另一個可憐的家伙繼承，並且您創建的命名標准可能會幫助那個可憐的家伙（“旅游開發者”，如果您願意）更輕松地導航在瘋狂中。

這是很多話題，所以讓我來談談。 這些是我的規則，但我認為它們可能對那些想要清理自己的代碼水族箱的人有所幫助：

1. 將一個類（或一個接口，枚舉或結構）放在一個文件中。
2. 類的名稱應該是文件的名稱。
3. 從同一基類繼承的類應位於同一文件夾中。
4. 如果可能的話，類應該與該類實現的接口位於同一文件夾中。
5. 接口應與類具有相同的名稱，但應使用大寫的“I”作為前綴。 這是我仍然尊重匈牙利人的唯一編碼建議。
6. 文件夾名稱應該是基類的復數版本。 例如，如果我們要創建一堆Engines ，則Engine應該是基類名， Engines應該是文件夾名，並且從Engine繼承的所有類都應該在Engines文件夾中。
7. 命名空間結構應直接遵循文件夾結構。 因此，應將一組給定Engines的命名空間（上面的示例）放入名為Engines的命名空間中。 如果Engines是子文件夾的子文件夾，則每個子文件夾應該是其自己的子命名空間，例如Project1.Subfolder1.Subfolder2.Engines 。
8. 當您處理需要存在於兩個單獨文件夾中的部分類時（因為該類的一部分是自動生成的），請將非自動生成的類放入以Extensions為后綴的文件夾中。 在文件中，注釋掉Extensions命名空間，如下所示： namespace FatDish.Engines//.EngineExtensions { ...

當涉及到導航性時，第一和第二規則是關鍵，因為它們直接幫助向“旅游開發者”指示任何給定的代碼片段所在的位置。

這就是我現在所能想到的。 更重要的是，你的約定與你采用任何特定形式的慣例一致。 這將有助於其他開發人員更快地理解和使用您的代碼，並確保項目的未來發展（由您自己以外的人編寫）保持在您已建立的相同的傳統，連貫的范圍內。

希望這可以幫助！

Answer 7

我個人堅持單一責任原則，我的每個班級都有一個行為

想想有一個電子商務網站

• 用戶注冊
• 用戶登錄
• 計費
• 供應商訂購

我將這些分離到User類，Billing Class和Orders類 - 然后遵循接口驅動的方法 - 每個責任的1個接口

檢查SOLID設計原則 - 每個類都將擁有自己的文件，並有一個合適的命名約定來幫助