Managing Enumerations

[ChrisB]

Hello:

I will be creating 50+ enumerations related to a large number of classes
that span a number of namespaces. I was wondering if there are any "best
practices" when defining enumerations.

Should a single class be created that contains all of a solution's
enumerations? Or should enumerations be defined directly in the files that
contain the related classes? Are there any other design patterns I am
overlooking?

Any thoughts?

Thanks!
Chris

[Dan Bass]

Perhaps others have differing opinions, but I've always kept things that are
global, global. That is to say that if an enumeration or constant is used in
several "random" places through out a project, then a global scope is a good
place for these to exist in.

If I find these global instances can be grouped together (a load of XML
constants for example) then I create a class within this Global class that
seperates and factors out this group. (Global.Xml)

If the constants are specific to a class and are not and should not be
referenced by other objects, then they belong to that class and I'd keep
them encapsulated there. Again grouping if the number of constants grows
sufficiently large.

I'd like to hear Mr Skeet's view on this.

Thanks
Dan.
"ChrisB" <pl****************@thanks.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Hello:

I will be creating 50+ enumerations related to a large number of classes
that span a number of namespaces. I was wondering if there are any "best
practices" when defining enumerations.

Should a single class be created that contains all of a solution's
enumerations? Or should enumerations be defined directly in the files that
contain the related classes? Are there any other design patterns I am
overlooking?

Any thoughts?

Thanks!
Chris

[Jon Skeet [C# MVP]]

<"Dan Bass" <danielbass [at] postmaster [dot] co [dot] uk>> wrote:

Perhaps others have differing opinions, but I've always kept things that are
global, global. That is to say that if an enumeration or constant is used in
several "random" places through out a project, then a global scope is a good
place for these to exist in.

If I find these global instances can be grouped together (a load of XML
constants for example) then I create a class within this Global class that
seperates and factors out this group. (Global.Xml)

If the constants are specific to a class and are not and should not be
referenced by other objects, then they belong to that class and I'd keep
them encapsulated there. Again grouping if the number of constants grows
sufficiently large.

I'd like to hear Mr Skeet's view on this.

Well, there are two different questions here: how the enums should be
grouped as far as the CLR is concerned, and how they should be grouped
in source code. As far as the CLR is concerned, I keep enums which are
only concerned with one class in that class, whether or not they should
be used by other classes - for instance, in an HTTP class (a layer over
WebRequest, effectively) I had a property which said which protocol to
use - the type was an enum, which was contained within that class
because it was only meant to be used *for* that class, even though
other classes would be specifying it. Other enums I treat as normal
types.

In terms of source code, I often group several small sets of enums
together, in a file called Enums.cs (only those in the same namespace,
of course). I do the same for delegates too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel O'Connell [C# MVP]]

Well, there are two different questions here: how the enums should be
grouped as far as the CLR is concerned, and how they should be grouped
in source code. As far as the CLR is concerned, I keep enums which are
only concerned with one class in that class, whether or not they should
be used by other classes - for instance, in an HTTP class (a layer over
WebRequest, effectively) I had a property which said which protocol to
use - the type was an enum, which was contained within that class
because it was only meant to be used *for* that class, even though
other classes would be specifying it. Other enums I treat as normal
types.

Whereas, personally, I woudl keep that enum external to the class because,
while the enum is only used *in* the one class, it will be used almost
exclusivly by other classes.

Its pretty tough to find consensus on this, I think.

[ChrisB]

Thanks to everyone for their input.

Chris

"Dan Bass" <danielbass [at] postmaster [dot] co [dot] uk> wrote in message
news:ez**************@TK2MSFTNGP15.phx.gbl...

Perhaps others have differing opinions, but I've always kept things that
are global, global. That is to say that if an enumeration or constant is
used in several "random" places through out a project, then a global scope
is a good place for these to exist in.

If I find these global instances can be grouped together (a load of XML
constants for example) then I create a class within this Global class that
seperates and factors out this group. (Global.Xml)

If the constants are specific to a class and are not and should not be
referenced by other objects, then they belong to that class and I'd keep
them encapsulated there. Again grouping if the number of constants grows
sufficiently large.

I'd like to hear Mr Skeet's view on this.

Thanks
Dan.
"ChrisB" <pl****************@thanks.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Hello:

I will be creating 50+ enumerations related to a large number of classes
that span a number of namespaces. I was wondering if there are any "best
practices" when defining enumerations.

Should a single class be created that contains all of a solution's
enumerations? Or should enumerations be defined directly in the files
that contain the related classes? Are there any other design patterns I
am overlooking?

Any thoughts?

Thanks!
Chris