同じファイルに複数のクラスを持つことは悪い習慣ですか？
以前は、1つのファイルに1つのクラスがありました。たとえば、car.csのクラスはcarです。しかし、さらに多くのクラスをプログラムするので、それらを同じファイルに追加したいと思います。たとえば、car.csにはクラスcarおよびdoorクラスなどがあります。
私の質問は、Java、C＃、PHPまたはその他のプログラミング言語に適しています。同じファイルに複数のクラスを含めないでください。それとも大丈夫ですか？
コードをファイルごとに1つのクラスに保つようにしてください。
後でクラスを見つけやすくなるため、これをお勧めします。また、ソース管理システムでうまく機能します（ファイルが変更された場合、特定のクラスが変更されたことがわかります）。
ファイルごとに複数のクラスを使用するのが正しいと思うのは、内部クラスを使用しているときだけです...しかし、内部クラスは別のクラス内にあるため、同じファイル内に残すことができます。内部クラスの役割は外部クラスと強く関係しているため、同じファイルに配置するのが適切です。
Javaでは、ファイルごとに1つのpublicクラスが言語の動作方法です。 Java=ファイルのグループをパッケージにまとめることができます。
ただし、Pythonでは、ファイルは「モジュール」であり、通常、密接に関連するいくつかのクラスがあります。 Python packageは、Java package。
これにより、Pythonクラスとパッケージ間のグループ化の追加レベルが提供されます。
言語に依存しない正しい答えはありません。言語によって異なります。
ファイルごとに1つのクラスが適切なルールですが、いくつかの例外を作成するのが適切です。たとえば、ほとんどのクラスにコレクションタイプが関連付けられているプロジェクトで作業している場合、クラスとそのコレクションを同じファイルに保持することがよくあります。例：
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
最良の経験則は、ファイルごとに1つのクラスを保持することです。ただし、それにより、物事が簡単になるのではなく、難しくなる場合があります。 Visual Studioのファイルの検索は非常に効果的であるため、とにかくファイル構造を調べるのに多くの時間を費やす必要はないでしょう。
いいえ、それは完全に悪い習慣ではないと思います。つまり、クラスごとに個別のファイルを用意するのが最善ですが、1つのファイルにクラスの束を置く方が良いという例外的なケースは間違いなくあります。これの良い例は、例外クラスのグループです。特定のグループにこれらの数十個がある場合、2つのライナークラスごとに個別のファイルを用意することは本当に理にかなっていますか？私は主張しないだろう。この場合、1つのクラスに例外のグループがあると、面倒で単純なIMHOがはるかに少なくなります。
複数のタイプを単一のファイルに結合しようとするたびに、単純にそれらを見つけやすくするという理由だけで、常に戻ってそれらを分離することを発見しました。私が結合するときはいつでも、最終的には、タイプxを定義したwtfを把握しようとする瞬間があります。
したがって、私の個人的なルールは、個々のタイプ（子クラスの場合を除き、継承されたクラスではなく、クラス内のクラス）が独自のファイルを取得することです。
チームで作業している場合、クラスを別々のファイルに保持すると、ソースの管理が容易になり、競合の可能性が減ります（複数の開発者が同じファイルを同時に変更する）。探しているコードも見つけやすくなると思います。
私がいつも通り抜けるルールは メイン 同じ名前のファイル内のクラス。そのファイルにヘルパークラスを含めるかどうかは、それらがファイルのメインクラスとどの程度密接に結合しているかによって決まります。サポートクラスはスタンドアロンですか、それとも単独で役立ちますか？たとえば、クラス内のメソッドがいくつかのオブジェクトをソートするために特別な比較を必要とする場合、比較ファンクタークラスをそれを使用するメソッドと同じファイルにバンドルすることは少し気になりません。私はそれを他の場所で使用することを期待しませんし、それが単独であるのは意味がありません。
将来の開発と保守性の観点からは悪いことです。 Car.csクラスがある場合は、Carクラスの場所を覚えるのがはるかに簡単です。 Widget.csが存在しない場合、どこでWidgetクラスを探しますか？車のウィジェットですか？エンジンウィジェットですか？たぶん、それはベーグルウィジェットです。
onlyファイルの場所を考慮する時間は、新しいクラスを作成する必要があるときです。それ以外の場合、Ineverファイル構造でナビゲートします。 「クラスに移動」または「定義に移動」を使用します。
これはややトレーニングの問題です。プロジェクトの物理的なファイル構造から解放するには、練習が必要です。それは非常にやりがいがあります;）
それらを同じファイルに入れるのが良いと感じたら、ゲストにしてください。 Javaただし;）のパブリッククラスでそれを行うことはできません。
[〜＃〜] ide [〜＃〜]は「Navigate to」機能を提供し、namespacingをある程度制御できるためあなたのクラス内では、同じファイル内に複数のクラスを持つことの以下の利点は私にとって非常に価値があります。
親-子クラス
多くの場合、継承クラスをベースクラスファイルに含めると非常に役立ちます。
子クラスが継承するプロパティとメソッドを確認するのは非常に簡単で、ファイルは全体的な機能のより速い概要を提供します。
パブリック：小-ヘルパー-DTOクラス
複数のplainとsmallが必要な場合特定の機能のクラスすべての参照とインクルードを含むファイルを用意するのは非常に冗長です4-8ライナー class .....
コードナビゲーションは、10個のファイルを切り替えるのではなく、1つのファイルをスクロールするだけでも簡単です... 10の代わりに1つの参照のみを編集する必要がある場合はリファクタリングも簡単です....
全体的にファイルごとに1クラスの鉄則を破ると、コードを整理するために余分な自由が追加されます。
そのとき何が起こるかは、実際にIDE、言語、チームコミュニケーション、および組織化スキルに依存します。
しかし、もしあなたがその自由を望むなら、なぜ鉄則のためにそれを犠牲にしますか？
プログラミングのほとんどの場合に当てはまるように、状況に大きく依存します。
たとえば、問題のクラスの凝集性はどうですか？それらは密結合ですか？それらは完全に直交していますか？機能的に関連していますか？
WebフレームワークがBaseWidget、TextWidget、CharWidgetなどを含む汎用のwidgets.whateverファイルを提供することは問題ではありません。
フレームワークのユーザーは、特定のドメイン空間のフレームワークウィジェットから派生した追加のウィジェットを含めるためにmore_widgetsファイルを定義することに不満はありません。
クラスが直交していて、互いに関係がない場合、単一のファイルへのグループ化は実際に人工的なものになります。自動車を製造するロボット工場を管理するアプリケーションを想定します。 CarPartsとRobotPartsを含むパーツと呼ばれるファイルは意味がありません...メンテナンス用のスペアパーツの注文と、工場が製造するパーツとの関係はほとんどありません。このような結合では、設計しているシステムに関する情報や知識は追加されません。
おそらく、最良の経験則は、経験則によって選択を制約しないことです。経験則は、最初のカット分析のため、または適切な選択を行うことができない人の選択を制限するために作成されます。ほとんどのプログラマーは、良い決断を下せると信じていると思います。
正当な理由がない限り、そうすることは控えるべきです。
いくつかの小さな関連クラスを持つ1つのファイルは、複数のファイルよりも読みやすくなります。たとえば、「ケースクラス」を使用してユニオン型をシミュレートする場合、各クラス間に強い関係があります。複数のクラスに同じファイルを使用すると、読者が視覚的にグループ化できるという利点があります。
あなたの場合、車とドアはまったく関連していないようで、car.csファイルでドアクラスを見つけることは予期しないことなので、そうしないでください。
経験則として、1つのクラス/ 1つのファイルを使用する方法です。ただし、1つのファイルに複数のインターフェイス定義を保持することがよくあります。 1つのファイルに複数のクラスがありますか？ very何らかの形で密接に関連していて、非常に小さい場合（<5メソッドとメンバー）
Smalltalkの答えは、（プログラミング用に）ファイルを持ってはいけないということです。バージョン管理とナビゲーションが苦痛になります。
ファイルごとに1つのクラスを維持する方が簡単で、コードを見る他の人にとってははるかに明確です。また、必須であるか、一部の言語では非常に制限されています。
Javaたとえば、ファイルごとに複数のトップレベルクラスを作成することはできません。クラス名とファイル名が同じ別々のファイルに存在する必要があります。