2011-01-20 21 views
2

我只是想知道其他人的想法是關於單個或單獨的.cs文件中的相關類?c#在不同的文件中有多個類?

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

謝謝。

回答

5

我總是爲每個班級單獨提供文件。這是建議的最佳做法,它確實有道理。

2

我的做法是,1文件== 1類/接口/模塊/ ...任何。 所以文件名總是反映那裏的內容。對我來說,這是最乾淨的方法。

1

我會把課程分成不同的檔案。這使得它們在IDE中更容易找到。

1

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

我會給文件下列名稱的.cs

這是推薦的最佳做法;它可以讓你快速找到你的課程。我總是用這種方法去做(除了當我有內部課堂時)。

-2

我個人堅持單一職責原則,在我的每個類都有一個單一的行爲

認爲有

  • 用戶註冊
  • 用戶登錄
  • 計費
  • 一個電子商務網站的
  • 供應商Ordering

我會將這些分爲用戶類,帳單類和訂單類 - 同樣會遵循接口驅動的方法 - 每個責任接口1個接口

檢查實體設計原則 - 然後每個類都將處於擁有自己的文件,並有一個合適的命名約定,以幫助

+1

我認爲這個回答與這個問題無關...... – 2011-01-20 10:31:42

1

我必須同意其餘的這裏:1 class = 1文件。

對於完整的項目名稱以及文件夾也使用正確的namespacing。接口也進入單獨的文件,但我通常保留其他類的枚舉和結構。

文件夾可用於將某些類組合在一起。然而,當你「用盡名字」這個話題時可能會遇到一個小問題。

例子:
解決方案:Tedd.CoolApp
項目:Tedd.CoolApp.Engine
現在應該做些什麼名字的類?我想命名它Engine,但那會給我Tedd.CoolApp.Engine.Engine ......:)

1

該計算機可以不關心你調製的文件夾結構,所以這個問題絕對屬於代碼可讀性的範疇。正如this post about standards of code readability,中提到的那樣,友好命名,一致性邏輯代碼分離是創建可讀代碼的基礎。

那麼,我們在哪裏呢?文件的創建 - 以及名稱空間和文件區域的創建 - 應該是一致的。名字應該是可以理解的。並且每個聚合類別中的代碼應該有一些共同點,應該在類別名稱中詳細說明。最終,爲了可讀性,您正在考慮您的代碼可能會被另一個可憐的人所遺傳,並且您創建的命名標準可能會幫助那位可憐的人(如果您願意的話,可以幫助「遊客開發人員」)更輕鬆地瀏覽在瘋狂中。

這是很多的談話,所以讓我下定決心。這是我的規則,但我認爲他們可能是有益的那些誰正在尋找清理自己的代碼水族館:

  1. 將一個類(或一個接口,枚舉或結構),在一個文件 。
  2. 該類的名稱應該是該文件的名稱 。
  3. 從同一基類繼承的類應位於同一個文件夾中。
  4. 如果可能的話,類應該與該類實現的接口位於同一個文件夾中。
  5. 一個接口應該與該類名稱相同,但應該以大寫的「I」作爲前綴。這是我仍然尊重Hungarians的唯一編碼建議。
  6. 文件夾名稱應該是基類的複數版本。例如,如果我們創建了一堆發動機引擎應該是基類名,發動機應該是文件夾的名稱,以及所有從引擎繼承的類應在引擎文件夾。
  7. 命名空間結構應直接跟隨文件夾結構。因此,給定的一組引擎(上面的示例)的名稱空間應放置在名爲引擎的名稱空間中。如果引擎是子文件夾的子文件夾,則每個子文件夾應該是它自己的子名稱空間,例如, Project1.Subfolder1.Subfolder2.Engines
  8. 當您處理需要生存在兩個單獨文件夾中的部分類時(因爲該類的一部分是自動生成的),請將非自動生成的類放入一個後綴爲擴展的文件夾中。在文件中,註釋掉擴展命名空間,如下所示:namespace FatDish.Engines//.EngineExtensions { ...

當談到通航,第一和第二個規則是關鍵,因爲他們在表明對「旅遊開發」直接援助,其中任何給定的一條代碼駐留。

這就是我現在能想到的。更重要的是,你在慣例中保持一致,而不是採用任何特定形式的慣例。這將有助於其他開發人員更快速地瞭解和使用您的代碼,並確保項目未來的發展(由除您以外的人撰寫)保持在您已建立的相同傳統且一致的範圍內。

希望這會有所幫助!

相關問題