同じファイルに複数のクラスを含めるのは悪い習慣ですか?


82

以前は、1つのファイルに対して1つのクラスがありました。たとえば、car.csにはクラスcarがあります。しかし、もっと多くのクラスをプログラムするので、それらを同じファイルに追加したいと思います。たとえば、car.csにはクラスcardoorクラスなどがあります。

私の質問は、Java、C#、PHP、またはその他のプログラミング言語に適しています。同じファイルに複数のクラスを含めないようにする必要がありますか、それとも問題ありませんか?

回答:


94

コードをファイルごとに1クラスに保つようにする必要があると思います。

後でクラスを見つけやすくなるので、これをお勧めします。また、ソース管理システムでより適切に機能します(ファイルが変更された場合、特定のクラスが変更されたことがわかります)。

ファイルごとに複数のクラスを使用するのが正しいと思うのは、内部クラスを使用しているときだけです...しかし、内部クラスは別のクラス内にあるため、同じファイル内に残すことができます。内部クラスの役割は外部クラスと強く関連しているため、同じファイルに配置しても問題ありません。


1
kotlinが1つのファイルで何ができるかを見た後、私はDTOのよ​​うないくつかのものが1つのファイルにある可能性があると信じ始めました。
ジョントライブ

1
これに加えて、同じファイルにあるクラスは通常密接に関連しており、複数のクラスを同時に表示するのは簡単ではないため、編集が難しくなる可能性があります。あなたはたくさんスクロールしなければなりません。分割ビューは役立ちますが、ファイル/クラスごとに個別のウィンドウを用意するほど簡単ではありません。
チャドヘッジコック2018

自動読み込みはどうですか?1つのソースファイルで複数のクラスを定義すると、自動読み込み機能がより複雑になります。stackoverflow.com/questions/37982012/を
AlexanderBehling20年

26

Javaでは、ファイルごとに1つのパブリッククラスが言語の動作方法です。Javaファイルのグループをパッケージに収集できます。

ただし、Pythonでは、ファイルは「モジュール」であり、通常、密接に関連するクラスがいくつかあります。Pythonパッケージは、Javaパッケージと同じようにディレクトリです。

これにより、Pythonはクラスとパッケージの間でさらにレベルの高いグループ化を行うことができます。

言語にとらわれない正しい答えはありません。言語によって異なります。


23

ファイルごとに1つのクラスが適切なルールですが、いくつかの例外を作成するのが適切です。たとえば、ほとんどのクラスにコレクションタイプが関連付けられているプロジェクトで作業している場合、クラスとそのコレクションを同じファイルに保持することがよくあります。例:

public class Customer { /* whatever */ }

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

経験則としては、ファイルごとに1つのクラスを保持することです。ただし、それによって問題が簡単になるのではなく難しくなる場合を除きます。Visual Studioのファイル内検索は非常に効果的であるため、とにかくファイル構造を調べるのに多くの時間を費やす必要はないでしょう。


3
いいえ。これは悪いアドバイスです。受け入れられた答えのアドバイスを受けてください。保存するクラスからオブジェクトリポジトリを分離する必要があります。それは単に不必要な混乱を引き起こします。
ハドソン

4
@Hudson上記の「オブジェクトリポジトリ」コードは表示されません。
ライアンランディ

18

いいえ、それが完全に悪い習慣だとは思いません。つまり、一般的には、クラスごとに個別のファイルを用意するのが最善ですが、1つのファイルに多数のクラスを含める方がよいという例外的なケースもあります。これの良い例は、例外クラスのグループです。特定のグループにこれらが数十ある場合、2つのライナークラスごとに個別のファイルを用意することは本当に意味がありますか?私は主張しません。この場合、1つのクラスに例外のグループを含めることは、それほど面倒で単純なIMHOではありません。


10

複数のタイプを1つのファイルに結合しようとすると、見つけやすくなるという理由だけで、常に戻ってそれらを分離することをやめることがわかりました。私が組み合わせるときはいつでも、私がタイプxを定義したwtfを理解しようとしている瞬間が常に最終的にあります。

だから今、私の個人的なルールは、個々のタイプ(おそらく子クラスを除いて、継承されたクラスではなく、クラス内のクラスを意味します)が独自のファイルを取得することです。


9

あなた以来IDEは「をご提供する移動機能」と、あなたはある程度制御持って名前空間を同一ファイル内の複数のクラスを持つことのメリットの下に、あなたのクラスの中の私にとって、それは非常に価値があります。

親-子クラス

多くの場合、基本クラスファイル内に継承クラスがあると非常に便利です。

子クラスが継承するプロパティとメソッドを確認するのは非常に簡単で、ファイルは全体的な機能の概要をより速く提供します。

パブリック:小-ヘルパー-DTOクラス

特定の機能のためにいくつかのプレーンクラスとスモールクラスが必要な場合、すべての参照を含み、4〜8個のライナークラスのみを含むファイルを用意するのは非常に冗長です。

コードナビゲーションは、10個のファイルを切り替える代わりに、1つのファイルをスクロールするだけでも簡単です... 10個ではなく1個の参照だけを編集する必要がある場合は、リファクタリングも簡単です。

ファイルごとに1クラスというIronのルールを全体的に破ると、コードを整理するための自由度が増します。

その場合に何が起こるかは、実際にはIDE、言語、チームコミュニケーション、および組織化スキルによって異なります。

しかし、あなたがその自由を望むなら、なぜそれを鉄の支配のために犠牲にするのですか?


7

チームで作業している場合、クラスを別々のファイルに保持すると、ソースの制御が容易になり、競合(複数の開発者が同じファイルを同時に変更する)の可能性が低くなります。探しているコードも見つけやすくなると思います。


7

私がいつも通っているルールは、同じ名前のファイルに1つのメインクラスを含めることです。ヘルパークラスがファイルのメインクラスとどの程度緊密に結合されているかに応じて、そのファイルにヘルパークラスを含める場合と含めない場合があります。サポートクラスはスタンドアロンですか、それとも単独で役立ちますか?たとえば、クラス内のメソッドが一部のオブジェクトを並べ替えるために特別な比較を必要とする場合、比較ファンクタークラスをそれを使用するメソッドと同じファイルにバンドルするのは少し面倒ではありません。他の場所で使用することは期待していませんし、それだけで使用しても意味がありません。


6

将来の開発と保守性の観点からは悪いことかもしれません。Car.csクラスがあると、Carクラスがどこにあるかを覚えるのがはるかに簡単になります。Widget.csが存在しない場合、Widgetクラスをどこで探しますか?車のウィジェットですか?エンジンウィジェットですか?多分それはベーグルウィジェットです。


2
stackoverflow.com/questions/360643/…で述べたように、一般的なナビゲーションツールを使用すると、とにかくファイルでナビゲートする必要はありません。代わりに、クラス/メンバーでナビゲートします。
スマ

6

唯一の私は、新しいクラスを作成しなければならないとき、私は、ファイルの場所を考える時間があります。それ以外の場合は、ファイル構造でナビゲートすることはありません。「クラスに移動」または「定義に移動」を使用します。

これはトレーニングの問題だと思います。プロジェクトの物理的なファイル構造から自分を解放するには、練習が必要です。それは非常にやりがいがあります;)

それらを同じファイルに入れるのが良いと感じたら、私のゲストになってください。しかし、Javaのパブリッククラスでそれを行うことはできません;)


2

経験則として、1つのクラス/ 1つのファイルが最適です。ただし、1つのファイルに複数のインターフェイス定義を保持することがよくあります。1つのファイルに複数のクラスがありますか?それらが何らかの形で非常に密接に関連していて、非常に小さい場合のみ(<5メソッドおよびメンバー)


2

プログラミングの多くの場合に当てはまるように、それは状況に大きく依存します。

たとえば、問題のクラスのまとまりは何ですか?それらは緊密に結合されていますか?それらは完全に直交していますか?それらは機能的に関連していますか?

Webフレームワークが汎用ウィジェットを提供することはラインから外れることはありません。BaseWidget、TextWidget、CharWidgetなどを含むファイルは何でも。

フレームワークのユーザーは、特定のドメインスペースのフレームワークウィジェットから派生した追加のウィジェットを含むmore_widgetsファイルを定義する際にラインから外れることはありません。

クラスが直交していて、互いに関係がない場合、単一のファイルへのグループ化は確かに人為的なものになります。自動車を製造するロボット工場を管理するアプリケーションを想定します。CarPartsとRobotPartsを含むパーツと呼ばれるファイルは無意味です...メンテナンス用のスペアパーツの注文と工場で製造されるパーツとの間にはあまり関係がない可能性があります。このような結合では、設計しているシステムに関する情報や知識は追加されません。

おそらく、最良の経験則は、経験則によって選択を制約しないことです。経験則は、最初のカット分析のために、または適切な選択を行うことができない人の選択を制限するために作成されます。ほとんどのプログラマーは、自分たちが良い決断を下せると信じたいと思います。


2

正当な理由がない限り、そうすることは控えるべきです。

複数の小さな関連クラスを持つ1つのファイルは、複数のファイルよりも読みやすくなります。たとえば、「ケースクラス」を使用して共用体型をシミュレートする場合、各クラス間に強い関係があります。複数のクラスに同じファイルを使用すると、読者が視覚的にそれらをグループ化できるという利点があります。

あなたの場合、車とドアはまったく関連していないようで、car.csファイルでドアクラスを見つけることは予期しないことなので、そうしないでください。


1

ファイルごとに1つのクラスを維持する方が簡単で、コードを見ている他の人にとってははるかに明確です。また、必須であるか、一部の言語では非常に制限されています。

たとえばJavaでは、ファイルごとに複数のトップレベルクラスを作成することはできません。それらは、クラス名とファイル名が同じである別々のファイルに存在する必要があります。


1

Smalltalkの答えは次のとおりです。(プログラミング用の)ファイルは必要ありません。それらはバージョン管理とナビゲーションを苦痛にします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.