Home > Archive > C# > May 2005 > Implementing enumerations that could change
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Implementing enumerations that could change
|
|
|
| Hi Everyone,
I have been designing a class that encapsulates the functionality of
a "Phone Number". I find that I am getting stuck on how to implement
the "type" of phone number the class represents. I started off by using
an enumeration such as..
Enum PhoneType
{
Work = 1,
Home = 2,
Mobile = 3
}
But as I thought more about it I wanted to be able to add more values
to the enumeration as the need arose. It would be best if I could store
the values of the enumeration in a database table. The problem is this:
If I am thinking of changing the members of the enum, is an enumeration
the best choice in the first place? I could use a class to represent
the "Type" of phone but it almost seems like overkill to use a class
just to enable the addition of future members of the "Phone Number
Type". Can anyone suggest a better way? Thanks.
-D
| |
| Bruce Wood 2005-05-30, 3:58 am |
| No, it's not overkill to use a class to encapsulate "phone number
type". If you're thinking of using a database table, then that's
sufficient evidence for me that "phone number type" is a "thing" in
your system and so you should represent it using a class. It is, after
all, a classification for phone numbers. That at least deserves a
simple object in memory, which is a class.
Even in its simplest incarnation, such as on my cell phone, a "phone
number type" has a name and an icon associated with it. Two pieces of
data = simple class.
Someday, you might want to associate different behaviours with phone
number types. For example, a work number could have an extension (or a
local), while a home number of a mobile number wouldn't. There may be
other cases. It's really starting to sound like a class, isn't it?
I would use a class. It's not overkill unless you have a fixed list of
phone number types that you know will never change, in which case use
an enum... but it sounds like you've outgrown that already.
| |
| Bruce Wood 2005-05-30, 3:58 am |
| For a good example of how a "class isn't overkill"... see the Color
class. It represents a simple colour, and has some properties that
return "constant" colours: Blue, Red, Green, etc. However, it's a
class, not an enum for the same reasons you're contemplating for "phone
number type."
| |
|
| It is a struct.. :)
"Bruce Wood" <brucewood@canada.com> schrieb im Newsbeitrag
news:1117430395.475676.305510@g49g2000cwa.googlegroups.com...
> For a good example of how a "class isn't overkill"... see the Color
> class. It represents a simple colour, and has some properties that
> return "constant" colours: Blue, Red, Green, etc. However, it's a
> class, not an enum for the same reasons you're contemplating for "phone
> number type."
>
| |
| Bruce Wood 2005-05-30, 3:58 pm |
| True. :)
The choice between class and struct has more to do with how you want
the thing to act than how "heavyweight" or "lightweight" you want it to
be, IMHO. You should consider using a struct only if:
1. You want the thing to act like a value, or
2. You're using it so intensely that you worry about the impact on
garbage collection and memory fragmentation... and you'd have to be
using it pretty intensely to worry about that.
You could make PhoneNumberType a struct if it contains an "enumeration"
value and nothing else. However, having made it a struct I would (if I
were you) comment it as a potential source of future bugs if anyone
adds more fields to it and starts trying to treat it like a class (that
is, expecting it to have reference semantics).
If you do make it a struct, make it immutable. That is, the only way to
set its values is in the constructor. No set accessors.
|
|
|
|
|