私はこの規則に従いますが、同僚の何人かはそれに同意せず、クラスが小さい場合、他のクラスと同じファイルに残すことができると主張しています。
私がよく耳にするもう1つの主張は、「Microsoftでもこれを行わないので、なぜ私たちがすべきなのか」というものです。
これについての一般的な合意は何ですか？これを避けるべきケースはありますか？
1
別のファイル
私はこの規則に従いますが、同僚の何人かはそれに同意せず、クラスが小さい場合、他のクラスと同じファイルに残すことができると主張しています。
私がよく耳にするもう1つの主張は、「Microsoftでもこれを行わないので、なぜ私たちがすべきなのか」というものです。
これについての一般的な合意は何ですか？これを避けるべきケースはありますか？
回答:
また、ファイルごとに1つのクラスを使用すると、ファイルの差分を見ずに、各チェックインの変更内容をより適切に把握できます。
人々が絶対的に考えて、これを絶対に誰かが愚かで正しいか間違っているかを理解する必要があるかのように、このような主観的で気の利いた何かで決してやるべきではないと言うとき、私はそれを嫌います。結論：理にかなっている場合、ファイルごとに複数のクラスがあることはまったく問題ありません。理にかなっていると私は次のようなことを意味します：
ファイルごとに複数のクラスが必要な理由の本当に良い例：
たとえば、数十のカスタム例外クラスがあり、それぞれが4ライナーであるとします。それぞれに個別のファイルを作成したり、例外をグループ化したり、グループごとにファイルを作成したりできます。私にとって最も合理的/実用的なアプローチは、それらをグループ化し、いくつかのファイルを用意することです。これは、時間/コーディングの点でより効率的であるためです（右クリック->クラスの追加、名前の変更、50回は不要です）。 、ソリューションが雑然としてなくなり、パフォーマンスが向上します。
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
return (rule.Overhead(useCase)
< My.PersonalThresholds.ConformismVsPracticality);
}クラスが密結合で、少なくとも1つが非常に小さい場合、ファイル内の複数のクラスをグループ化することがあります。
一般的な「ベストプラクティス」は、クラスごとに1つのファイルを用意することです。
架空の議論を超えて、代わりにVisual Studio IDEを備えたWindows .NETと成長しているソフトウェアプロジェクトに焦点を当てるだけで、このコンテキストでは、ファイルごとに1つのクラスを持つことが理にかなっています。
一般に、視覚的な参照では、ファイルごとに1つのクラスに勝るものはありません。本当に。
Microsoftが同じことをするかしないかはわかりませんが、1つのクラスを複数のファイルに分割するpartialキーワードを作成しました（これはさらに深刻です）。多くの場合、自動生成されたデザイナーコードをカスタムコードから同じクラスに分割するために使用されます（ただし、異なる開発者が異なるファイルを使用して同時にクラスで作業できるようにするために使用されることもあります）。したがって、Microsoftは複数のファイルの利点を認識しており、誰もが.NETで確実に複数のファイル編成の考えを持っています。
ネストされたクラスの場合、1つのファイル、または少なくともそれらのクラスの最初の部分を使用する以外に選択肢はありません。この場合、1つのファイルが必要であり、問題ありません。
class BicycleWheel {
class WheelSpoke {
}
}そうでない場合、なぜ複数のクラスを1つのファイルに保持するのでしょうか。「小さいので」または互いに関連付けられ ているという議論は、結局のところクラスが他のクラスに関連付けられるため、多くの水を保持しません。最終的には、特にソフトウェアが成長し続けるので、オブジェクトの使用状況に基づいてオブジェクトのファイル内編成を簡単に推測することはできません。
さらに、名前空間にフォルダーを使用する場合、クラスのファイル名が衝突することはありません。Visual Studioのような開発環境ではない場合（たとえば、メモ帳などのクイック/ライトでクラスをすばやく編集したい場合）、ファイルシステム上のファイル名でクラスを検索すると便利です。
非常に多くの理由があります...
partial私が言及したキーワードへの間接的な参照です。
partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx にすることができます。私はこれを好奇心から調べました。
私も、1つのファイルに1つのタイプを含める必要があると考えています。
このルールには1つの例外があります。それは、次のような一般的な引数だけが異なる2つのクラスがあることです。
RelayCommand そして
RelayCommand<T>1.cs for Foo <T> `とFoo 2.cs for Foo <T、T1>`があります。
Foo<T>し、Foo<U>同じ名前空間内。しかし、名前空間が異なる場合、それらは通常異なるフォルダーにあります。したがってためFoo<T>、およびFoo<U>それがFooのであるべきで1.cs and for はFoo <U、T> `Foo`2.cs。しかし、それでもファイルごとに1つのクラスです。
本当に、これは結局個人の好みに帰着します。誰もが「ファイルごとに1つのクラス」と言うでしょうが、私たちは皆、特定の状況でそれを回避する理由があります。私は以前、約300の列挙型を持つ大規模なプロジェクトを持っていました。いくつかの列挙型がトライステートのみだった場合、クラスごとに1つずつ、300個の個別のファイルを作成することはできません。
また、特定のクラスがすべて、それらが何であるかにちなんで名付けられたファイルに含まれていない場合、特定のクラスを見つけることができない人にとって、ソリューション全体で検索を使用しない理由はありますか？[検索]を使用すると、ソリューションエクスプローラーをスクロールする貴重な時間を節約できます。
私は通常、ファイルごとに1つのクラスを持っていますが、通常は自分の裁量を使用して、ファイルに関連するクラスが含まれているかどうかを確認する必要があります。この場合、ユーザーは複数のファイルではなく、1つのファイルのみを含める必要があります。
したがって、ポイントは次のとおりです。裁量を使用する必要があります!!!
大規模なソリューションでは、ファイルごとに1つのクラスがあり、ファイルにはクラスと同じ名前が付けられることが非常に価値があると思います。作業に必要なコードを簡単に見つけることができます。
C＃のStyleCopツールには、1つの名前空間に1つだけのトップレベルクラス（およびその名前空間の任意の数のインターフェイス、デリゲート、列挙型）を必要とする標準ルールがあります。
2番目以降のクラスが最初のクラスによってのみ使用される2つ以上のクラスの場合、それらは内部クラスである可能性があり、内部クラスである必要があります。
namespaceブロックを意味しますよね？
時々ファイルごとに1つのクラスですが ...
複数のクラスをstricly関連している場合、同じソースファイル内の複数のクラスは、私見、あるBETTER各クラスに短いソース・ファイルを専用に比べ。ソースはより読みやすくコンパクトです（#regionを使用すると、同じソースを以前よりも構造化できます）。
時にはそれがだとも考えてみましょうNECESSARY（使用して異なるファイル間で同じクラスを広めるために、部分的に 20000+ラインソース・ファイルを持つことは、私が用意して（これは別の問題です）RAMと便利でもないので、）。
小さなクラスを大きなクラスと一緒に残すこともありますが、それらがオブジェクトとコレクションクラスまたはファクトリーのように非常に密接に関連している場合のみです。
ただし、これには1つの問題があります。最終的に、小さなクラスは、それが独自のファイルにあるべきポイントまで大きくなります。それを新しいファイルに移動すると、変更履歴に簡単にアクセスできなくなります。
すなわち。
very tightly related分類し、それが画面のスペースを少ししか占有せず、他のクラスによって同じ目的で使用されない場合は、そのままにしておきます。
これは本当に問題なのでしょうか？:)
enumのように、本当に小さなクラスは他のクラスと一緒に置くことができます。従うべきルールが1つあります。共通するものがあるクラスのみをまとめます。
余談ですが、私のプロジェクトの1つに、内部に150のクラスがあるファイルがあります。ファイルには10000行のコードがあります。しかし、それは自動生成されるので、完全に許容できます:)
1 つのファイルに複数の関連クラスを配置する理由の1つは、APIを使用する貧しい野郎がインポート宣言のボイラープレートを入力するのに半日費やす必要がなく、コードを保守する必要のある貧しい野郎が半分費やす必要がないためです。インポート宣言のボイラープレートをスクロールする1日。私の経験則では、ほとんどの場合、一度に1つだけではなく、同時に大きなサブセットを使用する場合、複数のクラスが同じファイルに属します。
私はこれを行いますが、クラスが親子関係で関連付けられており、子クラスが親によってのみ使用されている場合のみです。
私は通常、ファイルごとに1つのクラスを使います。ただし、プロジェクト全体で使用される類似の構成要素のグループについては例外を設けます。例えば：
EventArgsサブクラスを含むEventArgs.cs 。これらは通常、それぞれ5行から10行のコードですが、通常、いくつかの異なるクラスで使用されます。または、EventArgsイベントを宣言するクラスと同じファイルにクラスを配置することもできます。enumプロジェクト全体で使用されるを含むEnums.cs 。（enum1つのクラスでのみ使用されるものが存在する場合、通常はprivateそのクラスに到達します。）これまでの応答は、ルールに対する人々の例外を中心に展開しているように見えるので、これは私のものです。それ以外の場合は、常に別のファイルにあります。ほとんどの場合、知っています。そうでない場合を除きます。
One case could be:あなたのクラスは、共同で形成するときmodule / unitのようないくつかの主要なクラス働くことがhelper classes、他の賢明なノーを。
ASP.NET MVC 2.0プロジェクトのソースコードをご覧ください。このルールに厳密に従います
これまでに投稿された回答で言及されていないファイルごとに1クラスのもう1つの理由は、ファイルごとに1クラスを使用すると、コードレビュー中にPRの影響を理解しやすくなるためです。また、マージの競合も減少します。
誰かがフィードバックのためにPRを投稿すると、変更されたファイルのリストを見ることができ、私が取り組んでいるものとの重複をすぐに確認できます。オーバーラップによっては、自分のコードに深く影響を与えたり、自分の変更に影響を与えたりすることはないと確信しているので、OKにしたいと思うかもしれません。
2人がマルチクラスファイルで作業していて、両方が依存関係を追加している場合using、上部のブロックでマージの競合が発生する可能性が高くなります。クラスをファイルに分離すると、依存関係が分離されるため、各クラスが使用しているものを確認でき、このような競合が発生しなくなります。
このルールには例外があります（インターフェース+実装、列挙型など）が、通常、ジュニア開発者がすべての種類の無関係なクラスを同じファイルにバンドルできるようにする反対よりも良い出発点です。
ファイルごとに1クラスは、解釈の対象とならない明確で明確なルールです。
ファイル内の関連クラスは、個人的な好みと解釈の影響を受け（使用できるかどうかに関する他のすべての回答からわかるように）、したがって、不適切なルールです。
個人と個人の例外はあるものの、クラスとファイル間の1-1マッピングが大多数の意見であるという私の一般的な印象はありますが、前後は非常に興味深いもので、一見決定的ではありません。
あなたの答えがあなたが次のどちらであるかによって異なるかどうか、私は興味があります。（1）Windowsフォームアプリ、Webアプリ、ライブラリ、またはその他の開発 または（2）Visual Studioを使用するかどうか。VSを使用する場合、他のスレッドのコンセンサスはVSソリューション/プロジェクトをディレクトリ/ファイルの名前と構造にミラーリングする必要があるため、ファイルルールごとに1つのクラスはVSプロジェクトごとに1つのクラスを意味するように見えます。確かに、私の印象は、コンセンサスがプロジェクト名=アセンブリ名=（ネストされた）名前空間名を持つことであり、それらはすべてディレクトリ/ファイルの名前と構造に反映されます。これらが適切なガイドライン（またはルール）である場合、これらの外見上は直交する組織化メカニズムはすべて同期されます。