Daniel Pitts wrote :
On Aug 27, 4:59 pm, Wojtek <nowh...@a.com> wrote:
Daniel Pitts wrote :
You should consider ... and also adding methods to
your enum to replace switch branches.
I do not like placing business logic into what is basically a selector.
This particular enum selects which database engine is being used. It is
used in 100's of abstract classes. Which would mean I would need either
100's of methods, or a really complex factory class.
--
Wojtek :-)
If its being used in 100's of abstract classes, that means you have
100's of switch statements. Wouldn't polymorphism be the better
approach by far? Perhaps using enum isn't exactly what you intended.
Instead of getDatabaseSelector(), you could write one method that is
called getDatabaseEngine(), and it will return to you an
implementation of your database engine.
I use an enum to enforce the type. I use a switch because it is more
"elegant" than an if/else tree. I have 100's because each use case is
logically separated (as much as possible) from every other use case.
It may not wring every last bit of performance out of the CPU, it may
not be 100% OO, but it IS easy to read (understand), easy to implement
(new UC's), and easy to maintain (minimal interaction between UC's).
--
Wojtek :-)