The idea seems to be to pump all entity functions through some generic method. And then have some
"auto-configuring" methods that act as convenient "chicken", "fish", "pasta" buttons.
But isn't that the same as having methods like "findByAnd" pumped through methods like
"findListIteratorByCondition"? That is, isn't the worker class idea already currently implemented?
But I do agree that it's nice to organize the "chicken" "fish" "pasta" buttons into a neat
"control panel" (your worker class), and leave the innards in some class say "BewareInnardClass".
Jonathon
Adrian Crum wrote:
Jonathon -- Improov wrote:
This is a very crucial point in this thread.
A heavily parameterized method is great for genericity. We can call
such a method with programmatically generated parameters. Very
consistent, very single-entry-point approach.
However, such a method will require "setting up" of the parameters
before calling it.
In comparison, having a few buttons named "chicken", "fish", "pasta"
on a microwave oven will allow me to just press the button for the
common scenario I'm facing at the moment. I don't need to think about
how much heat a chicken can take, compared to a fish.
That's why I was thinking we would still need some kind of worker class
that can be called to prepare the handful of objects we have in hand so
they can be used in the single entry point. The worker class would
function as the chicken, fish, and pasta buttons.
The worker class would provide more than just convenience - it would
help keep overall code size down.
Let's say we have the one or two methods David proposed, and it takes an
average of ten lines of code to prepare data for those methods. If there
are 100 places in the project where that data preparation is needed,
then we've just added 1000 lines of code to the overall project. With a
worker class, we can reduce that to one additional line of code per
instance, or 100 lines total.
-Adrian
