Implementing enumerations that could change

  • Thread starter Thread starter dwok
  • Start date Start date
D

dwok

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
 
dwok said:
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.
Click to expand...


There are several ways to go about this and I base it off whether an enum
will provide me with sufficient information, and whether the end user can
customize the available phone types.
I use enums if I as a programmer decides what is available and there is no
additional information required for each enum, i.e. I have a textual
representation and a numerical representation for persisting to a database.
If you want the list to be customized by the end user and perhaps other
additional information is needed for each enum type then maintaining a
collection of PhoneTypes is the way to go.
Ask yourself what is going to happen when your customer calls up and says
"where do I put the person's beeper number?".

Regards,
SP
 
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.
 
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."
 
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.
 
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.
Click to expand...

In some cases for example Matrices it is useful if they are mutable, but
yes, generelly it is not.
 
Back
Top