Daniel Pitts wrote:
you might consider using polymorphism instead. I.E. create a
ChecksErrors interface and an implementation of that interface for
every ErrorID. Then have a lookup table (probobably Map<Integer,
ChecksErrors> or ChecksErrors[], depending on the range of ErrorID).
Hope this helps.
Daniel.
P.S. Hard coding behavior is NOT a bad thing. You're programs behavior
is to do something different depending on the ErrorID, so having a
"hard coded" switch in this case is not a Bad Thing.
The polymorphic handler idea is very powerful, and it's how frameworks like
Struts and JSF work, for example. The lookup table can be instantiated from a
resource like a property file at program initialization.
When confronted with a switch off of an (essentially) enum value set,
polymorphism is usually the better choice. Plug in the handler that would've
been the method reached from the switch, but is now a class implementing a
common handle() (or do(), execute(), whatever()) method that knows how to
handle its use case.
The Map can be Map< ErrorID, Class<? extends ChecksErrors>>, that way you can
instantiate a new handler for each invocation instead of worrying about
re-using the same handler object each time.
--
Lew
Spring to give you dependency injection. That way you're