Consider I have an enum, which I have coded today. What are the possible ways to extend its functionality, or perhaps add more variables to it, on a later date? Will partial enums do the trick?
+4
A:
It really depends on who is using the enum. If it is just your own code, then you can probably add more values to it without any side-effects, since you should ideally already be checking explicitly for the expected values. It is generally pretty easy to track down any places that need editing.
It gets trickier if the enum has been released for other people to consume as part of an API; for example, if you add "MyNewValue" to an enum used in the return of a web-method, that could cause existing clients (that haven't yet been updated) to crash when you send them that value - either through the code not knowing what to do, or (more immediately) by the serialization layer panicking when it sees a string it didn't expect.
There is no such thing as a partial enum; only class, struct or interface.
Marc Gravell
2010-04-27 04:28:23
so how is it, if it has been released as an API?
Soham
2010-04-27 05:31:13
@Soham - with great care. Sure, you can rebuild and redeploy the dll, but it may have consequences.
Marc Gravell
2010-04-27 05:57:55
@Soham: If you are writing a reusable library, please read the Framework Design Guidelines (http://www.amazon.com/dp/0321545613). The book has 13 pages designing enums (paragraph 4.8). Marc is totally right about the compatibility risk of adding values to enums. The FDG say about this: _"CONSIDER adding values to enums, despite a small compatibility risk."_
Steven
2010-04-27 06:39:43
Good Point, but in reality, no such dll is released. I might one day, or I might not. I might even release the code to public, or I might not. So the point effectively is, I want to incorporate the best coding practices so that one day anybody can improve, modify and extend the functionality in a jiffy (long shot, as the only marker of a good code and a bad code is WTFs/min:) ) But then, we can always try.
Soham
2010-04-28 04:22:03
@Soham - then the critical thing is to correctly *handle* the enum values; don't assume that it *must* be one of the 6 defined today - because that isn't even true today (enum values aren't checked; I can assign -145515 to your enum quite happily)
Marc Gravell
2010-04-28 05:24:41
So do I create another enum value to take care of all junk assignments?)
Soham
2010-04-29 08:41:15