Re: Class Constants - pros and cons
On Wed, 28 Jul 2010, Lew wrote:
One can even have custom code *per enum value* which makes implementing
state patterns a breeze.
I have not so far encountered a real-life situation where a 'switch' on
an enum value is cleaner or more desirable than using enum polymorphism.
For state machines I'm more likely to use a Map (or EnumMap) to look up
a consequent state than a switch. Have any of you all found good use
cases for a 'switch' on an enum?
We've done it once. We have some internationalisation code where,
approximating wildly, items can be internationalised by locale or by
country (ie shared across all languages in a locale - prices are the
classic example). We have an enum called something like LocalisationType
with values LOCALE and COUNTRY to identify which is being done. We do have
some polymorphism around it (not actually in the enum, although for the
purposes of this story, that's not interesting), related to the core
business of finding out the right localisation key (locale code or country
code) and resolving the item value for it.
But we also have other bits of code which are not core functionality which
need to do different things for locale- and country-keyed items. The one
that springs to mind is a locale copying utility - if you're copying fr_FR
into CA to create fr_CA (obviously, only as a starting point for manual
editing), you want to copy locale-mapped items (which will be
French-language text) but not location-mapped items (which will be prices
in euros and so on). We could have put a shouldCopyWhenCopyingLocale()
method on the enum, or even a copyIntoNewLocale() method which did nothing
in the location case, but this seemed like polluting the enum with
behaviour that belonged in the copier. So we put a switch in the copier
instead.
There's probably a more OO-clean way to break the decision up, but this
was simple and worked, so that was good enough for us.
tom
--
Know who said that? Fucking Terrorvision, that's who. -- D