Re: Using enums to avoid using switch/if
Giovanni Azua wrote:
In conclusion, even when enum types would be a very strong match for a
design, these limitations would defeat using it.
Mark Space wrote:
I had exactly the same problem with a little test program I wrote to
suss out Item 34 of Effective Java, "Emulate extensible enums with
interfaces."
In a larger sense, EJ's advice is part of a larger concept of type-
based programming. Since enums can implement interfaces it's possible
to make enums appear to be of a particular type. This could be useful
in certain circumstances.
However:
The facts that you cannot derive new classes from existing enum classes,
and the inability to derive from a common abstract base class, are just
too limiting in almost every circumstance. If the enum refers to some
value that could change or need to be extended later, it's better to not
use an enum.
This is the point - enums are not the class for every season. They
have a particular use case for which they are extremely well suited.
That is a fairly large use case; even with the restrictions, that an
enum is a full-fledged class in its own right gives it tremendous
power and flexibility. For use cases that fall outside that range,
well, you just have to use a different kind of class. You could, for
example, write a type-safe enumeration like Josh Bloch recommended in
the first edition of EJ. You can't use it in a 'switch', but in other
respects you can make it as much like an enum as you need, and you can
make it heritable if you want. Beware of the oddities inherent in
using static members of a class from its subclasses.
--
Lew