Design guidelines for Enumeration

Question

In one of the financial Winform projects , the application code will have to work with values such as currencies. In the object model that represents business entities , there are fields that need to hold currency values such as USD , EUR , etc. The set of values for this field will most probably be limited to one of the standard currencies and rarely will it need to be expanded for new currencies. The application gets the currency inputs from a GUI control that brings these values from another standard source and displays as a dropdown, although it is possible that user inputs a value directly into the control. The application's logic does not specifically depend on the values of the currency and no special process is performed on these fields directly that demands referring to the actual values contained in the fields.

Now for the question : Is it advisable to use an enumeration , that enumerates values such as USD , EUR and the likes, so that currency values received into the code can be validated against the enumeration ? If not , is it advisable to leave it to the fact that the currency values are input from a dropdown , so that no extra validations be needed in code ?

Answer 1

If the code doesn't process the currency value, and if new currency value can be added later, then I'd encode currency values as (data) strings instead of as (hard-coded) enum values.

Answer 2

As you have a limited and fixed set of possible values, an enumeration or pre-populated drop down are better than allowing the user to enter their own values. (An enumeration is possibly more efficient as it can be stored in as little as one byte if you have fewer than 256 currencies). Another approach (if you envisage that it might be possible one day that another currency needs to be added) would be to populate a drpo-down from an XML configuration file or database table so that it is data-driven and easily extended (rather than requiring a rebuild of the application to support the new currency)

Be careful with enumerated types if you plan to Obfuscate your code - once obfscated, you cannot convert the enum values to text (as they will be "scrambled") so you can no longer use reflection to convert between enumerated values and text (for filling UI controls and/or serialisation to text formats)

Answer 3

IMO you should create an enumeration with the allowed values and validate the input. The reason is because you may have one interface with a dropdown but there is nothing preventing other interfaces to use simple text entries for example.

Answer 4

I recommend you create a simple class or event struct for currency, and also create few static readonly members for currently defined currencies:

class Currency
{
     public static reaonly IEnumerable<Currency> Currencies = new List<Currency>
     {
         new Currency { Name = "USD", CurrencySign = "$" },
         new Currency { Name = "EUR", CurrencySign = "€" }
     }

     public string Name {get; private set;}

     public string CurrencySign {get; private set;}

     public override ToString() { return Name; }
}

It allows you to easy extend currency list and extract it from other places then static member, like database or web service without redesing your application.