Where do enumerations belong

Question

At my current place of employment they were putting enumerations into the class they used them in. Whilst I didn't see any duplication of these enumerations I non the less thought that they didn't belong in the class so I moved them out into their own class.

The reason I did that was that I wanted them to be re-usable w/out needing to reference the model class they were originally in.

I got asked why I did that by the boss disagreed with me as to my reasons for moving them and saw nothing wrong with putting enumerations in a model class.

So where should they be? Is it acceptable to leave enumerations in a class and hope that others in the project know to refactor your code if they want to re-use it elsewhere or should, as I did, you create an enumerations class and have them all in there?

Answer 1

I like to keep them in a separate package under model - I find I often end up using them as method parameters and this aids reuse and claririty when browsing

Answer 2

As long as the enum is in the same namespace, I don't see a big deal where they are located. Perhaps the biggest driving factor would be what the standard practice is wherever you work.

Answer 3

(I'm writing from the perspective of a Java developer)

Enumerations are, in many cases, replacements to magic numbers.

Like the magic numbers they replace, they are usually only relevant in a single context or a small context - the type in which they are declared or the hierarchy.

If you find a single enumeration shared or duplicated in many locations, that is occasionally an indication that your type hierarchy itself is missing some abstraction, so look at your interfaces and classes.

Only if your enumeration is very global (e.g, a cross-cutting thing like "OK" and "Cancel") should you put it, IMHO, in sort of a global type. For example, the SWT gui toolkit has an SWT class with various globals, including enumerations.

Answer 4

If the enumeration is semantically related to the enclosing class, i.e. specifying symbolic names for class options, then they belong in the class. If they're not semantically related, then move them up a level to their own class. Be aware that if you detach the enumeration from the enclosing class, you may have increased coupling between classes.

Answer 5

First thing first.

• I always makes sure a code file contains a single type, not 2 types or 3 types. Even if it's private and only used in that class. And the reason I prefer it that way is that it's much more easier to find it, when it comes down to it.

• The namespace always matches the folder hierarchy, and a code file always has the same name as the type inside:

  namespace Foo.Bar.FooType { class FooType...

  Foo\Bar\FooType.cs

• Always group your related types (physically) together as it makes sense. Don't use folders like "Model", "View" or "Controller". That just shows that someone doesn't know what MVC is really about. Related does not mean that you should have a "Constants" folder or a "Enums" folder, no! Sometimes it may be the case, but you should try not to.