TL; DR : 일반적으로 디자인이 잘못되기 때문에 열거 형 모음을 사용하는 것은 좋지 않습니다. 열거 형 모음은 일반적으로 특정 논리를 가진 고유 한 시스템 엔터티를 요구합니다.
열거 형의 몇 가지 사용 사례를 구별해야합니다. 이 목록은 내 머리 위에 만 있으므로 더 많은 사례가있을 수 있습니다 ...
예제는 모두 C #에 있으며, 선택한 언어가 비슷한 구문을 갖거나 직접 구현할 수 있습니다.
1. 단일 값만 유효합니다
이 경우 값은 배타적입니다. 예 :
public enum WorkStates
{
Init,
Pending,
Done
}
Pending과 (과 ) 모두 같은 작업을하는 것은 유효하지 않습니다 Done. 따라서이 값 중 하나만 유효합니다. 이것은 열거 형의 좋은 사용 사례입니다.
2. 값의 조합이 유효합니다.
이 경우는 플래그라고도하며 C #은 [Flags]이러한 작업에 열거 형 속성을 제공합니다 . 아이디어는 각각 하나의 열거 형 멤버에 해당하는 bools 또는 bits 세트로 모델링 될 수 있습니다 . 각 구성원은 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
}
열거 형 멤버 컬렉션을 사용하는 것은 각 열거 형 멤버가 설정되거나 설정되지 않은 하나의 비트 만 나타내는 경우에 무리가 있습니다. 대부분의 언어가 이와 같은 구문을 지원한다고 생각합니다. 그렇지 않으면 하나를 만들 수 있습니다 (예 :을 사용 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) 일부 값의 조합은 유효하고 일부는 유효하지 않습니다
이것은 빈번한 시나리오입니다. 하나의 열거 형에 두 가지 다른 것을 넣는 경우가 종종 있습니다. 예:
[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와 Window의를 위해, 아주 보통이 아니다 Building들 가지고 Wheel들.
이 경우, 열거 # 1 또는 # 2a를 달성하기 위해 열거를 부분으로 나누거나 객체 계층을 수정하는 것이 좋습니다.
디자인 고려 사항
어쨌든 열거 형은 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; }
}
즉 - 그것은 그, 암시 적 UserA는 User, 추가 정보는 그가 여부입니다 Admin.
당신이 배타적이지 여러 역할을 할 수있는 경우 (예를 들어이 User될 수있다 Admin, Moderator, VIP, ... 같은 시간에), 그 중 하나가 플래그 열거 형 사용하는 것이 시간 또는 abtract 기본 클래스 또는 인터페이스가 될 것입니다.
클래스를 사용하여 주어진 조치를 수행 할 수 있는지 여부를 결정할 책임이있는 책임을 Role더 잘 분리 Role합니다.
열거 형을 사용하면 모든 역할에 대해 한곳에 논리가 있어야합니다. 어느 것이 OO의 목적을 무너 뜨리고 다시 명령해야합니다.
에 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));
}
}
열거 형을 사용하는 것이 허용 가능한 접근 방법 일 수 있습니다 (예 : 성능). 여기서 결정은 모델링 된 시스템의 요구 사항에 따라 다릅니다.