Is it possible to save a type (using "typeof ()") in an enumeration?

Question

So, I am creating a game in XNA, C # 4.0, and I need to manage a lot of PowerUps (which in the code all inherit from the PowerUp class), and to control the internal management of PowerUps, I currently have enum, PowerupEffectType, with a value for each child PowerUp class. In the end, in the code, I need to make the conversion from PowerupEffectType to the Powerup type (of the Type class, achieved usually with typeof([class name]) ).

Since this is a group project, I want to marry each PowerupEffectType value to its corresponding class type, and also, possibly: i.e. not just expect my other programmers to use switch statements to do the conversion manually, and make sure that add-ons / extensions in the future assume as few changes as possible in as many places as possible. I have several options for this, and the best I've discovered so far is to create pseudo-enum methods that condense all up to one switch statement (99% of what I want), thanks to some tips that I found here : http://msdn.microsoft.com/en-us/library/bb383974.aspx

But I'm trying to do it one more step - can I save Type in enum ? I know that you can save enums as a specific type (link: http://msdn.microsoft.com/en-us/library/cc138362.aspx ), but Type not one of them. The current selections are byte, sbyte, short, ushort, int, uint, long and ulong. Is there a possible way to save a Type conversion to any of the above data types and vice versa?

Just to be clear, this is what I WISH I could do, and I'm looking for a way to do:

 // (Assuming 'LightningPowerup', 'FirePowerup', and 'WaterPowerup' are // all declared classes that inherit from a single base class) public enum PowerupEffectType { LIGHTNING = typeof(LightningPowerup), FIRE = typeof(FirePowerup), WATER = typeof(WaterPowerup) } 

Is there a way to do this, or am I just overdoing the solution to a problem that is already 99% complete?

Thanks in advance!

Answer 1

You cannot do this as an enumeration value, but you can specify it in the attribute:

 using System; using System.Runtime.CompilerServices; [AttributeUsage(AttributeTargets.Field)] public class EffectTypeAttribute : Attribute { public Type Type { get; private set; } public EffectTypeAttribute(Type type) { this.Type = type; } } public class LightningPowerup {} public class FirePowerup {} public class WaterPowerup {} public enum PowerupEffectType { [EffectType(typeof(LightningPowerup))] Lightning, [EffectType(typeof(FirePowerup))] Fire, [EffectType(typeof(WaterPowerup))] Water } 

You can then retrieve these attribute values ​​at run time with reflection. However, I would just create a dictionary:

 private static Dictionary<PowerupEffectType, Type> EffectTypeMapping = new Dictionary<PowerupEffectType, Type> { { PowerupEffectType.Lightning, typeof(LightningPowerup) }, { PowerupEffectType.Fire, typeof(FirePowerup) }, { PowerupEffectType.Water, typeof(WaterPowerup) } }; 

There is no need for a special attribute; there is no need to retrieve values ​​using code with indecision.

Answer 2

This is not quite what you are asking. I find John's attribute method the best. But why not wrap it in an extension method?

 public Type GetPowerupEffectType(this PowerupEffectType powerEffect) { switch (powerEffect) { case LIGHTNING: return typeof(LightningPowerup); case FIRE: return typeof(FirePowerup); case WATER: return typeof(WaterPowerup); default: return default(Type); } } 

And call him:

 PowerupEffectType e = PowerupEffectType.WATER; var t = e.GetPowerupEffectType(); 

Answer 3

How about something like that?

You get the type of security you do with the enumeration, plus implicit conversion to type

 public class PowerupEffectType { private readonly Type _powerupType; public static implicit operator Type(PowerupEffectType powerupEffectType) { return powerupEffectType._powerupType; } private PowerupEffectType(Type powerupType) { _powerupType = powerupType; } public static readonly PowerupEffectType LIGHTNING = new PowerupEffectType(typeof(LightningPowerup)); public static readonly PowerupEffectType FIRE = new PowerupEffectType(typeof(FirePowerup)); public static readonly PowerupEffectType WATER = new PowerupEffectType(typeof(WaterPowerup)); } 

Answer 4

You can use static Dictionary<PowerupEffectType, Powerup> . I believe that this will be the “marriage” that you are looking for. This will make it easy to list and access.

Answer 5

You can use only numeric types, as in the Microsoft documentation. By default, the base type of each element in the enumeration is int. You can specify another integer numeric type using a colon, as shown in the previous example. See the listing for a complete list of possible types. Link: enumeration types

Answer 6

Sorry, I don’t quite understand what you are really trying to achieve; could you give a snippet of code? I'm not sure why you cannot just use inheritance here and that the listing gives you this type of inheritance. It seems to me that you are presenting a solution, not a problem, I may be completely wrong, could you explain how you plan to use this meta-information?

I'm confused, are you asking for something that tells you the instance type of a type / class? You can use an enumeration to store a list of types of each type that you say, but why do you want? You say you don’t want other programmers to use switch statements, but I'm sorry that I don’t see what benefit you get from storing type information in some kind of enumeration ... type. Each instance knows what type it is and what it can do.

What will you do with type information? If all types are inherited from the base type, then, apparently, they have common functionality that can be specified in the abstract method to handle any particular case or, possibly, return a Null Object , where there is nothing to do (or maybe just do nothing). This way, you don’t have to worry about adding new classes, as they should have the necessary behavior. I try to avoid Enum , except when you are actually listing a fixed set of arbitrary values, they are inflexible. Enum , which is very difficult (in practice).

Answer 7

I really think you can take a look at the dependency injection infrastructure.

It looks like you are trying to get other developers to work with various components, and then trying to combine them all at the end in one central place in the code base.

Several projects to view:

• http://www.ninject.org/
• http://docs.structuremap.net/
• http://archive.msdn.microsoft.com/mef