On Apr 7, 2008, at 9:02 AM, David Avendasora wrote:
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.
Consider it from a different point of view. You have parts that can
be composed of sub-parts. There are two sub-classes,
1. SimplePart (aka RawMaterial). This never has any sub-parts.
2. ComplexPart (aka ManufacturedPart). This has one or more sub-parts.
In this scenario, Part.subParts() makes sense for all types.
So I have modeled it like this:
ManufacturedPart ->> BillOfMaterial ->> BOMComponent -> Part
What is BOMComponent? Why not just ManufacturedPart ->>
BillOfMaterial ->> Part
Or, in my terminology ComplexPart ->> ConstructionDescription ->> 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.
Why are you iterating over Parts calling billOfMaterial()? What is
the goal? What exactly are you doing with this information? I have
an idea of what you are missing, but I will wait for an answer to this.
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.
Still seems wrong.
Chuck
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.
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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]
