I think Dwayne is referring to the fact that, once you've gone beyond having
one table or object class to model each real-world "thing", the criteria you
apply in each method for discovering your other artefacts are quite
different.
A "good" relational design is (roughly) that contains one entity for each
real-world thing, *plus* one entity in every place where an "intersection
entity" is required to avoid many-to-many relationships.
You would never dream (normally) of having an entity (hence table) to model
a collection of items, as distinct from a single item. In relational design,
you normally try to avoid creating design artefacts that are only there to
make processing easier (and anyway, it wouldn't). The idea is to reflect the
inherent structure of the data - which is why well-normalised relational
designs support a variety of processing tasks. So presumably Deanna would
have a Task table and a Consumable table. Nothing else.
In OO design, the idea of modelling real-world objects doesn't take you very
far, once you've got your basic objects. (In an OO design you wouldn't
normally model intersection entities.) Clearly Deanna wants a Task object,
and probably a Consumable one too. But beyond that, it's purely a question
of using efficient/elegant design patterns.
My answer to the original question
> When you're designing an object that includes a multiple has-a type
> >relationship, do you typically build the objects such that their is an
> >intermediate "collection" type object?
would be, I would normally define the parent object to contain a collection
of the child objects. But I wouldn't design a special object to model that
collection, I'd just use a built-in class.
But to be honest, if I was using CF, OO design methodology would not be at
the forefront of my mind.
Nick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
