C＃の列挙型には独自のファイルが必要ですか？
列挙型を使用するクラスがあり、列挙型は現在、独自のファイルにあり、無駄が多いようです。
それらが消費されるファイルの名前空間内に配置されている列挙型に関する一般的な意見は何ですか？または、列挙型は独自のcsファイルに実際に存在する必要がありますか？
編集
問題のクラスがこれらの列挙を使用する一方で、外部の呼び出し元も使用することに言及する必要があります。つまり、別のクラスでこれらの列挙を設定できます。したがって、クラスの内部で使用されることはありません。そうでない場合、この質問は簡単なことではありません。
「無駄」とは言いませんが（余分なファイルの費用はいくらですか？）、それはしばしば不便です。通常、enumに最も密接に関連付けられているクラスが1つあり、それらを同じファイルに入れます。
これは本当に好みの問題です。
私は各列挙を独自のファイルに配置することを好みます（同様に、インターフェース、クラス、および構造体ごとに、どんなに小さくても）。私が別のソリューションから来ている場合、または問題のタイプへの参照をまだ持っていない場合、それらを見つけやすくします。
また、各ファイルに単一のタイプを入れると、ソース管理システムの変更を区別せずに識別しやすくなります。
これは完全にスタイルの問題です。私がしがちなのは、enum宣言が収集されるソリューションにEnums.csというファイルを作成することです。
しかし、それらは通常、 F12 とにかくキー。
自問する質問は、C＃の列挙型について、作成する他のすべての型とは異なる方法で扱う必要があることを示すものはありますか？
列挙がパブリックの場合、他のパブリックタイプと同様に扱う必要があります。プライベートの場合、それを使用するクラスのネストされたメンバーとして宣言します。 1つが列挙であるという理由だけで、2つのパブリックタイプを同じファイルに配置する説得力のある理由はありません。パブリックタイプであるという事実だけが重要です。タイプのフレーバーはそうではありません。
各タイプ（クラス、構造体、列挙型）を独自のファイルに入れることのもう1つの利点は、ソース管理です。タイプの履歴全体を簡単に取得できます。
以下のように、その名前空間内の他のクラスに簡単にアクセスできるように、ほとんど名前空間内とクラス外に配置します。
namespace UserManagement
{
public enum UserStatus { Active, InActive }
class User
{
...
}
}
一般的に、enumは、おそらく属性となるClassと同じファイルにあることを好みます。たとえば、クラスTaskがある場合、enum TaskStatusは同じファイルにあります。
ただし、より汎用的な列挙型がある場合は、さまざまなファイルにコンテキストに応じて保持します。
どのアクセスが必要かによって異なります。
列挙型が単一のクラスでのみ使用されている場合、他の場所で使用する必要がないため、そのクラス内で列挙型を宣言してもかまいません。
複数のクラスまたはパブリックAPIで使用される列挙型の場合、適切なネームスペースの独自のファイルに常に定義を保持します。その方法を見つけるのははるかに簡単で、戦略はファイルごとに1つのオブジェクトのパターンに従います。これは、クラスやインターフェイスでも使用するのに適しています。
列挙型のスコープに依存すると思います。たとえば、enumが1つのクラスに固有であり、たとえば魔法の定数のシナリオを回避するために使用される場合、クラスと同じファイルにそれを配置すると言います。
enum SearchType { Forward, Reverse }
列挙型が一般的であり、さまざまなシナリオで複数のクラスで使用できる場合、それを独自のファイルに入れて使用することになります。たとえば、以下はいくつかの目的に使用できます。
enum Result { Success, Error }
私は非常に単純な理由で列挙型を独自のファイルに配置する傾向があります：クラスや構造体と同様に、exactly知っているのはいいですタイプの定義を見つけるには：同じ名前のファイル内。 （公平を期すために、VSでは常に「Go to Definition」も使用できます。）
明らかに、手に負えなくなる可能性があります。私が働いている同僚は、代理人のために別のファイルを作成します。
Visual Studio用のUSysWare File Browserアドインを使用している場合、ソリューション内の特定の名前のファイルを非常にすばやく見つけることができます。独自のファイルではなく、巨大なソリューションのいくつかのファイルに埋もれている列挙型を探していると想像してください。
小規模なソリューションの場合は重要ではありませんが、大規模なソリューションの場合は、独自のファイルにクラスと列挙型を保持することがさらに重要になります。それらをすばやく見つけたり、編集したりできます。 enumを独自のファイルに配置することを強くお勧めします。
そして、述べられたように...とにかく数キロバイトに過ぎないファイルはどれほど無駄なものですか？
列挙に個別のファイルを使用する利点の1つは、列挙を使用した元のクラスを削除し、列挙を使用して新しいクラスを作成できることです。
列挙型が元のクラスから独立している場合、それを別のファイルに入れると、将来の変更が容易になります。
ファイルを分離する非常にシンプルで大きな利点。オブジェクトが独自のMyObjectName.csファイルにある場合、ソリューションエクスプローラーに移動してMyObjectName.csと入力すると、1つのファイルのみが表示されます。デバッグを改善するものは何でもいいです。
すべてのファイルを検索する場合の同様のメモに関する別の利点（ctrl+shft+F）名前については、同じファイル内の名前への20の参照を見つけることができます...その見つかった名前は異なるオブジェクトの一部になります。 [検索結果]ウィンドウに表示されるのは、行番号とファイル名のみです。ファイルを開いてスクロールし、見つかった参照がどのオブジェクトに含まれているかを把握する必要があります。
デバッグを簡単にするものは何でも好きです。
各列挙型を含むEという名前の1つのパブリック列挙型ファイルを作成したいので、E ...を使用してすべての列挙型にアクセスできます。それらは1か所で管理できます。
1つのソリューションに複数のプロジェクトがある場合。次に、別のプロジェクトUtilitiesを作成します。次に、フォルダー\Enumerationsを作成し、ネストされたstatic classを作成します。そして、プロジェクトの名前に対応する列挙型を作成する各静的クラスを割り当てます。たとえば、DatabaseReaderおよびDatabaseUsersという名前のプロジェクトがある場合、次のように静的クラスに名前を付けることができます。
public static class EnumUtility {
#region --Database Readers Enum
public static class EnumDBReader {
public enum Actions { Create, Retrieve, Update, Delete};
}
#endregion
#region --Database Users Enum
public static class EnumDBUsers {
public enum UserIdentity { user, admin };
}
#endregion
}
次に、プロジェクトごとのソリューション全体で使用できる列挙全体が宣言されます。 #regionを使用して、各懸念を分離します。これにより、列挙型を探しやすくなります