TL; DR：多くの場合、不適切なデザインにつながるため、列挙型のコレクションを使用することは悪い考えです。通常、列挙型のコレクションは、特定のロジックを持つ個別のシステムエンティティを呼び出します。
enumのいくつかのユースケースを区別する必要があります。このリストは私の頭の一番上にあるので、もっと多くのケースがあるかもしれません...
例はすべてC＃で記述されています。選択する言語は同様の構成要素を持っているか、自分で実装できる可能性があります。
1.単一の値のみが有効です
この場合、値は排他的です。例えば
public enum WorkStates
{
Init,
Pending,
Done
}
両方のあるいくつかの作業を持って無効であるPendingとしますDone。したがって、これらの値の1つのみが有効です。これは、enumの適切な使用例です。
2.値の組み合わせは有効です。
この場合はフラグとも呼ばれ、C＃は[Flags]これらを操作する列挙属性を提供します。アイデアはのセットboolまたはbit、それぞれが1つの列挙メンバーに対応する sの。各メンバーには2の累乗の値が必要です。組み合わせは、ビット演算子を使用して作成できます。
[Flags]
public enum Flags
{
None = 0,
Flag0 = 1, // 0x01, 1 << 0
Flag1 = 2, // 0x02, 1 << 1
Flag2 = 4, // 0x04, 1 << 2
Flag3 = 8, // 0x08, 1 << 3
Flag4 = 16, // 0x10, 1 << 4
AFrequentlyUsedMask = Flag1 | Flag2 | Flag4,
All = ~0 // bitwise negation of zero is all ones
}
列挙型メンバーのコレクションを使用すると、各列挙型メンバーが設定または設定解除された1ビットのみを表すような場合に過剰になります。ほとんどの言語はこのような構造をサポートしていると思います。それ以外の場合は、作成できます（例：bool[]してアドレス指定(1 << (int)YourEnum.SomeMember) - 1）。
a）すべての組み合わせが有効です
いくつかの単純なケースではこれらは大丈夫ですが、タイプに基づいて追加の情報や動作が必要になることが多いため、オブジェクトのコレクションの方が適切な場合があります。
[Flags]
public enum Flavors
{
Strawberry = 1,
Vanilla = 2,
Chocolate = 4
}
public class IceCream
{
private Flavors _scoopFlavors;
public IceCream(Flavors scoopFlavors)
{
_scoopFlavors = scoopFlavors
}
public bool HasFlavor(Flavors flavor)
{
return _scoopFlavors.HasFlag(flavor);
}
}
（注：これは、アイスクリームのフレーバーのみを本当に気にすることを前提としています-アイスクリームをスクープとコーンのコレクションとしてモデル化する必要はありません）
b）値のいくつかの組み合わせは有効であり、いくつかは無効です
これはよくあるシナリオです。多くの場合、2つの異なるものを1つの列挙型に入れています。例：
[Flags]
public enum Parts
{
Wheel = 1,
Window = 2,
Door = 4,
}
public class Building
{
public Parts parts { get; set; }
}
public class Vehicle
{
public Parts parts { get; set; }
}
それは両方のために完全に有効ですが今VehicleとBuilding持っているDoorsおよびWindowSをするために、それは非常に普通のではないBuildingsが持っているWheelのを。
この場合、＃1または＃2a）のいずれかのケースを達成するために、enumを複数の部分に分割し、オブジェクト階層を変更することをお勧めします。
設計上の考慮事項
どういうわけか、エンティティのタイプは、enumによって通常提供される情報に類似していると見なすことができるため、enumはOOの駆動要素ではない傾向があります。
たとえば、IceCream＃2からサンプルを取り、IceCreamエンティティはフラグの代わりにScoopオブジェクトのコレクションを持ちます。
それほど純粋ではないアプローチはScoop、Flavor財産を持つことです。純粋主義のアプローチはScoop、の抽象基底クラスになることですVanillaScoop。ChocolateScoop代わりに、...クラス。
要点は次のとおり
です。1.「何かのタイプ」であるすべてのものを列挙する必要はありません
はない2.いくつかの列挙型メンバーが有効なフラグではない場合、列挙型を複数の異なる列挙型に分割することを検討してください。
今、あなたの例のために（わずかに変更されました）：
public enum Role
{
User,
Admin
}
public class User
{
public List<Role> Roles { get; set; }
}
この正確なケースは次のようにモデル化されるべきだと思います（注：実際には拡張可能ではありません！）：
public class User
{
public bool IsAdmin { get; set; }
}
言い換えれば、それは暗黙的であり、であることUserがUser、追加情報は彼がAdminです。
あなたが排他的ではありません複数の役割を持って取得する場合（例えばUserすることができAdmin、Moderator、VIP、...同時に）、それはどちらかのフラグが列挙型を使用するには良い時間やabtract基底クラスまたはインタフェースになります。
クラスを使用して表現することRoleによりRole、特定のアクションを実行できるかどうかを決定する責任を持つことができる責任の分離が改善されます。
列挙型を使用すると、すべてのロールのロジックを1か所にまとめる必要があります。これはオブジェクト指向の目的を打ち負かし、あなたを命令に戻します。
にModerator編集権限があり、編集権限Adminと削除権限の両方があると想像してください。
列挙型アプローチ（Permissionsロールと権限を混在させないために呼び出されます）：
[Flags]
public enum Permissions
{
None = 0
CanEdit = 1,
CanDelete = 2,
ModeratorPermissions = CanEdit,
AdminPermissions = ModeratorPermissions | CanDelete
}
public class User
{
private Permissions _permissions;
public bool CanExecute(IAction action)
{
if (action.Type == ActionType.Edit && _permissions.HasFlag(Permissions.CanEdit))
{
return true;
}
if (action.Type == ActionType.Delete && _permissions.HasFlag(Permissions.CanDelete))
{
return true;
}
return false;
}
}
クラスアプローチ（これは完璧にはほど遠い、理想的にIActionは、ビジターパターンにしたいのですが、この投稿はすでに膨大です...）：
public interface IRole
{
bool CanExecute(IAction action);
}
public class ModeratorRole : IRole
{
public virtual bool CanExecute(IAction action)
{
return action.Type == ActionType.Edit;
}
}
public class AdminRole : ModeratorRole
{
public override bool CanExecute(IAction action)
{
return base.CanExecute(action) || action.Type == ActionType.Delete;
}
}
public class User
{
private List<IRole> _roles;
public bool CanExecute(IAction action)
{
_roles.Any(x => x.CanExecute(action));
}
}
ただし、列挙型を使用することは、許容可能なアプローチ（たとえば、パフォーマンス）である場合があります。ここでの決定は、モデル化されたシステムの要件に依存します。