在同一個文件中有多個類是不好的做法嗎？

Question

我曾經有一個類爲一個文件。例如car.cs有類汽車。但是，當我編程更多的課程時，我想將它們添加到同一個文件中。例如car.cs有類車和門類等

我的問題是很好的Java，C＃，PHP或任何其他編程語言。我應該嘗試在同一個文件中沒有多個類，還是沒問題？

Answer 1

我認爲你應該儘量讓你的代碼每個文件1個類。

我建議這樣做，因爲稍後會更容易找到你的課程。此外，它可以更好地處理源代碼管理系統（如果文件發生更改，那麼您知道某個類已更改）。

我認爲對每個文件使用多個類的唯一時間是使用內部類時......但內部類在另一個類內，因此可以留在同一個文件中。內部類的角色與外部類緊密相關，所以將它們放在同一個文件中是很好的。

Answer 2

我發現，每當我嘗試將多個類型合併爲一個文件時，我總是會回頭並將它們分開，因爲它使它們更容易找到。每當我結合起來，總會有一個時刻，我試圖找出wtf我定義的類型x。

所以，現在我的個人規則是，每個單獨的類型（除了子類，也就是說類中的類，而不是繼承類）都有自己的文件。

Answer 3

從未來的發展和可維護性角度來看，這可能是不好的。如果你有Car.cs類，記住Car類的位置要容易得多。如果Widget.cs不存在，你會在哪裏尋找Widget類？它是一個汽車小部件嗎？它是一個引擎小部件嗎？哦，也許這是一個百吉餅小部件。

Answer 4

如果您正在團隊中工作，將類保存在單獨的文件中可以更輕鬆地控制源並減少衝突的可能性（多個開發人員同時更改同一文件）。我認爲它更容易找到你正在尋找的代碼。

Answer 5

只有時間我認爲文件位置是當我必須創建新的類。否則我從來沒有導航文件結構。我使用「上課」或「去定義」。

我知道這是一個培訓問題;擺脫項目的物理文件結構需要練習。這是非常有益的，但;）

如果感覺很好，把他們在同一個文件中，成爲我的客人。不能用java中的公共類來實現;）

Answer 6

作爲一個經驗法則，一個類/一個文件是要走的路。不過，我經常將幾個接口定義保存在一個文件中。一個文件中有幾個類？只有當他們都非常莫名其妙密切相關的，和非常小的（< 5方法和成員），每個文件

Answer 7

一類是易於維護和其他人在看你的代碼更加清晰。這也是強制性的，或者在某些語言中非常受限制。

在Java中，例如，不能爲每個文件創建多個頂級類，它們必須位於類名和文件名相同的單獨文件中。

Answer 8

在Java中，一個公開每個文件的類是語言的工作方式。一組Java文件可以被收集到一個包中。

然而，在Python中，文件是「模塊」，通常有許多緊密相關的類。 Python包就像Java包一樣是一個目錄。

這給了Python在類和包之間的額外級別的分組。

沒有一個與語言無關的正確答案。它隨語言而變化。

Answer 9

我總是經歷的規則是在一個具有相同名稱的文件中有一個主類。我可能會也可能不會在該文件中包含幫助程序類，具體取決於它們與文件主類的耦合程度。支持類是獨立的，還是它們自己有用？例如，如果某個類中的某個方法需要對某些對象進行排序的特殊比較，那麼它就不會打擾我將比較函子類與使用它的方法捆綁到相同的文件中。我不希望在其他地方使用它，它是獨立的沒有意義。

Answer 10

每個文件一個類是一個很好的規則，但適合做一些例外。舉例來說，如果我在大多數類有關聯集合類型的一個項目我工作，我常常會保持類和它在同一個文件集合，例如：

public class Customer { /* whatever */ } 

public class CustomerCollection : List<Customer> { /* whatever */ } 

拇指最好的規則是每個文件保留一個類，除非開始讓事情變得更難而不是更容易。由於Visual Studio的「在文件中查找」功能非常有效，因此您可能無需花費太多時間瀏覽文件結構。

Answer 11

在程序設計中這麼多時候都是如此，這很大程度上取決於情況。

例如，有問題的類的凝聚力是什麼？它們是緊密結合的嗎？它們是完全正交的嗎？他們在功能上有關係嗎？

它不會是脫節的web框架供應widgets.whatever含有BaseWidget，TextWidget，CharWidget文件的通用等

框架的用戶不會是脫節的定義一個more_widgets文件，用於包含它們從其特定域空間的框架小部件派生出來的其他小部件。

當這些類是正交的，並且與彼此無關時，將其分組爲單個文件確實是人爲的。假設一個應用程序來管理構建汽車的機器人工廠。一個名爲包含CarParts和RobotParts的零件的文件將毫無意義......維護的備件訂購和工廠製造的零件之間不太可能存在很大關係。這樣的加入不會增加關於您正在設計的系統的信息或知識。

也許最好的經驗法則是不要用經驗法則來約束你的選擇。經驗法則用於第一次分析，或限制那些不能做出正確選擇的人的選擇。我想大多數程序員都希望相信他們有能力做出正確的決定。

Answer 12

不，我不認爲這是一個完全不好的做法。我的意思是通常最好每個類都有一個單獨的文件，但肯定有很好的異常情況，最好在一個文件中有一堆類。一個很好的例子就是一組Exception類，如果你對某個給定的組有一個這樣的幾個這樣的類，那麼爲每個兩個班輪類使用一個單獨的文件是否真的有意義？我不會爭辯。在這種情況下，在一個類中有一組例外是非常麻煩和簡單的恕我直言。

Answer 13

Smalltalk的答案是：你不應該有文件（用於編程）。他們使版本控制和導航痛苦。

Answer 14

你應該避免這樣做，除非你有充分的理由。

一個文件與幾個小相關類可以比幾個文件更具可讀性。 例如，當使用'case class'時，爲了模擬union類型，每個class之間都有很強的關係。 對多個類使用相同的文件具有將它們以可視方式分組在一起的優點。

在你的情況，有車有門似乎並不在所有相關的，並找到在car.cs文件大門類將是意想不到的，所以不要。

Answer 15

由於您IDE爲您提供「導航到」功能，你必須在一些控制命名空間的類中然後在同一文件中有多個類的下方好處是相當值得的我。

父 - 子類

在許多情況下，我覺得很有幫助的繼承其基地類文件中類。

然後很容易看到子類繼承哪些屬性和方法，並且該文件提供了有關整體功能的更快概述。

市民：小 - 助手 - DTO類

當你需要幾個平原和小類爲特定功能我覺得很冗餘與所有的引用文件，包括只是一個4-8班輪類.....

代碼導航也更容易滾動o NE文件，而不是交換文件10之間...它也更容易重構時，你必須編輯只是一個參考，而不是10 .....

總體每個文件突破1級的鐵律提供一些額外的自由來組織你的代碼。

然後會發生什麼，真的取決於您的IDE，語言，團隊溝通和組織技巧。

但是，如果你想要那種自由，爲什麼要犧牲它的鐵律呢？