You know, I was hoping to avoid the whole question if the domain was
actually well-modeled or not, but with such dispersions cast on my
flawless modeling skills, I must respond! :-P
I have 2 types of Parts. One purchased from an outside vendor
(RawMaterial), and ones that are manufactured (ManufacturedPart). A
ManufacturedPart is made up of any number of component Parts. These
component Parts can be _either_ a RawMaterial or another
ManufacturedPart.
So I have modeled it like this:
ManufacturedPart ->> BillOfMaterial ->> BOMComponent -> Part
To make things more complicated each given Manufactured Part can have
one or more ways of making it and therefor have multiple
BillsOfMaterial.
Hence, I have a branching, recursive relationship tree that can be any
number of levels deep:
ManufacturedPart ->> BillOfMaterial ->> BOMComponent ->
ManufacturedPart ->> BillOfMaterial ->> BOMComponent ->
ManufacturedPart ->> Rinse, lather, repeat.
Or it can be very simple
ManufacturedPart ->> BillOfMaterial ->> BOMComponent ->> RawMaterial
What all this comes down to is that billsOfMaterial() does _not_
belong on Part as it does not belong on RawMaterial because a
RawMaterial is NOT manufactured by us so it will never have a
BillOfMaterial.
But there are several places in my code that I want to recursively
navigate this tree and I just don't see a "right" way to do that
without some variation of instanceOf (in code or in a fetch), a case
statement or adding the method to Part.
The simplicity of one simple method returning NSArray.emptyArray wins.
Even though it sullies my object graph, it does so in a much less
complicated, fragile way.
Dave
On Apr 7, 2008, at 11:26 AM, Chuck Hill wrote:
The real question is whether it makes sense in the domain for a Part
to have a bill of materials. The default implementation could be
public NSArray billOfMaterials() { return this; }
With complex parts overriding it as appropriate. It could just be
that the model / design is incomplete and leading David into doing
Bad Things in code.
Otherwise, (a) the model is just wrong, or (b) David's processing is
just wrong.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
