[Cronometer-development] Re: Design of food/datasource

[Chris R. <ch...@of...>]

A bit more on examination...

The issue here is with an unfortunate mix of action/dependency
methods.  There are some parts of each class that handle things that
should be handled in other classes.  For example, an SQLFood should
handle writing itself to the database, not the datasource.  The whole
point of the Food interface is to separate that out, and I should have
done that work back when I split things out into interfaces.

I'm starting to think that the nutrientTable class needs to be looked
at again, too -- as mentioned below, the reflection-based design
forces code changes if we want to take on additional nutrients, where
a map-based (and factory patterned) NutrientTable single class with a
private constructor and hashmap nutrient names (which can be populated
from the schema, even -- this is not a large stretch) would be more
flexible in the long run.

I think that the latter of those two is easier to do, and might put my
head back in the right space for working with this.  The downside to
the changes I'm proposing here is that they will of necessity change
the way the interface to the food data sources operates.  I'll try to
minimize it, but I can't guarantee anything.  Saving and loading
foods, especially, will change.  Essentially, once you have a Food,
you should no longer need to know about its datasource, so long as you
know if you can edit it (to which end I have split Food into Food and
MutableFood, which inherits from it)

On 10/10/05, Chris Rose <ch...@of...> wrote:
> I know that this is mainly my fault -- I should have examined this in
> the redesign, but in adding the functionality to distinguish identical
> foods, I have come across a flaw in the design of the food/datasource
> model.
>
> The issue, as I see it, is that the datasource is too tightly coupled
> to HOW the food is stored in the backing store, especially w/r.to the
> writeable foods.  What needs to happen is that all writes to the food
> tables need to be handled internally to the food (EJB-style -- I
> wonder if a future rewrite could use the Spring framework?) and the
> datasource just needs to handle the aggregation and searching of the
> contents of the store.
>
> So, the upshot of this is, I need to tear the guts out of the
> datasources and make them more...  robust in order to make the
> duplicate food problem go away, and render this whole bag of code more
> maintainable over the long term.
>
> I'm also a bit skeptical about the use of reflection to map nutrients
> -- it leads to a relatively small set of code in the child classes, to
> be sure, but I think I can accomplish the same with a hashmap and a
> string array, and let the code be more extensible over the long term.
> With permission, I'll go in and make that change, as well.
>
> Back on track :)
> --
> Chris R.
> =3D=3D=3D=3D=3D=3D
> Not to be taken literally, internally, or seriously.
>


--
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.