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