Separate class for enums? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

What is the general consensus towards a separate class in the business layer to store the definition of enums? Is this bad practice? Does this conform to good n-tier design? At the moment my enum definitions are dotted around different, what I would deem as, relevant classes - but I feel as though they should be in one place. Is this, in fact, a subjective question and relative to how I've structured the rest of the solution?

Answer 1

Keeping enums in separate class

In this case you're tossing unrelated definitions into one class, for almost no benefits.

Defining enum as nested type for class it relates to

When you hold enums within a class, you may run into naming troubles:

class Foo
{
    public enum SomeType { /* ... */ }
    public SomeType SomeType { get; set; }
}

This would give an error that SomeType is already defined.

It probably just boils to personal taste, but most often I put my enums along with the class that they are related to, without nesting them:

public enum SomeType { } 
public class Foo { }

I was tempted many times to have them nested (we're talking about public enums of course), but the naming issues weren't worth it, for example:

class Foo
{
    public enum Enumeration { }
}

Then I can use such enum outside of Foo class, as: Foo.Enumeration, but following declaration (in same namespace):

enum FooEnumeration { }
class Foo { }

gives similar result as you just don't have to type '.' when you are referencing enum: FooEnumeration. Moreover, the latter allows you for this:

class Foo
{
    public FooEnumeration Enumeration { get; set; }
}

which would cause aforementioned naming conflicts in previous case.

Summary

When using IDE with powerful GoTo capabilities, it seems to me that naming issues are far more important than 'physical' localization of the enum definition.

Answer 2

I don't really understand why you would place an enum in a class - perhaps you meant file?

Personally I have a separate file for each enum with the name of the enum.

I place this file close to where the enum is being used and namespace it accordingly.

If an enum is to be shared across assemblies/namespaces, I will use the lowest shared namespace, so it is visible to the using namespaces.

Having enums close to where they are used will make separating code out into projects that little bit easier (if needed).

I don't see the point in having them all in one file - navigation wise, Visual Studio has more than enough navigation capabilities that this is not needed.

Answer 3

I would prefer having separate classes for all constants and Enums in my projects.It improves readability of the code. You should do it especially if you have a Comman proj you are referencing in your business layer and other layers. But if you'd be adding unnecessary references just for the sake of a Constant/Enum class then having them inside the same project makes more sense.

public class Enumerations
{
 public enum Gender{
   Male = 0,
   Female = 1,
   Unknown = 2
 }
}

And when you consume you could do it like

GetPerson(Enumeration.Gender gender)
{

}