简体   繁体   中英

C# Static vs enum for readonly variables

Say for instance you have the following class:

    public static class TimeType
{
    public static String DAY = "Day";
    public static String WEEK = "week";
    public static String MONTH = "month";
    public static String YEAR = "year";
}

Now when programming you would be able to access or these variables.

My question is would it be better to have them as an Enum ?

The way i want to use these variables is as such:

    private DateTimeIntervalType GetIntervalType()
    {

        switch (TimeType)
        {
            case "week":
                return DateTimeIntervalType.Weeks;
            case "month":
                return DateTimeIntervalType.Months;
            case "year":
                return DateTimeIntervalType.Years;
            default:
                return DateTimeIntervalType.Days;
        }
    }

Don't be afraid to create a custom type.

You could go with something like this:

// omitted error-/equality checking for brevity
public sealed class TimeType
{
    private static Dictionary<string, TimeType> _dic = new Dictionary<string, TimeType>();

    public static TimeType DAY   = new TimeType("Day", DateTimeIntervalType.Days);
    public static TimeType WEEK  = new TimeType("week", DateTimeIntervalType.Weeks);
    public static TimeType MONTH = new TimeType("month", DateTimeIntervalType.Months);
    public static TimeType YEAR  = new TimeType("year", DateTimeIntervalType.Years);

    public string Name { get; private set; }
    public DateTimeIntervalType Type { get; private set; }

    private TimeType(string name, DateTimeIntervalType type)
    {
        Name = name;
        Type = type;
        _dic[name] = this;
    }

    public static TimeType GetByName(string name)
    {
        return _dic[name];
    }

    public static IEnumerable<TimeType> All()
    {
        return _dic.Values;
    }
}

and use this type like a enum, but it's more powerful (no need for a switch anymore):

// looks like a enum
var day = TimeType.DAY;

// Get the DateTimeIntervalType directly
DateTimeIntervalType day_interval = day.Type;

// Get the correct TimeType by a string
var month = TimeType.GetByName("Day");

// Get all TimeTypes
var allTypes = TimeType.All();

This type of data makes sense to use an enum for. I'd structure your enum in the following way though:

public enum DateTimeIntervalType
{
    None = 0, // this is a sensible default so you always have to define which
    Days = 1,
    Weeks = 2, // all are numbered so any changes don't rely on order of enum
    Months = 3,
    Years = 4
}

Then instead of your switch statement you can use:

var interval = (DateTimeIntervalType)Enum.Parse(
                    typeof(DateTimeIntervalType), 
                    text);

Then you can use your enum as usual:

if (someEnumValue == DateTimeIntervalType.Weeks)
{
    // do something
}

and

switch(someEnumValue)
{
    case DateTimeIntervalType.Days:
        // something
        break;
    case DateTimeIntervalType.Weeks:
        // something
        break;
}

If you want to have an enumeration, use an enum structure. If you want to have a value accesible from anywhere in your code that belongs inside of a specific class, then use static.

But if all you want is a value that cannot change, you may consider using a "const".

As commented by dav_i, in this case you are better of using an enum.

Enum is just something like an Alias for a numeric value. So if you want to have strings as you have them in your question, than enums are not the right thing for you.

to get the names from enums, you then have to use Reflection , and Reflection is not the fastest way to do that.

I guess using enum is better since the datatype of the flag does not matter if it was string or integer. also enums is a very meaning full way to group flags together.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM