On Apr 7, 2008, at 10:50 AM, David Avendasora wrote:
On Apr 7, 2008, at 1:23 PM, Chuck Hill wrote:
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.
I'm not sure how this is much different conceptually than what I
have already.
It is not. I was just using different names so you might look at it
with fresh eyes. I find that tricks like that sometimes help break
out of a path of thinking.
The problem is that I cannot simplify it that far because there may
be 5 or more ways of making a given part depending upon which
Manufacturing Line is being used, the time of year, wether or not a
piece of equipment on the manufacturing line is broken-down or not,
etc. I do have the concept of the "default" BillOfMaterial for a
given Part, but that is controlled by the user setting a flag on the
one they want to be default.
So, in theory I could have convenience methods that return the
"subParts" of the default BillOfMaterial for the given Part, but in
most cases, that is not useful information for my users. I need to
know much more before I can say what the subParts are.
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
It's actually even more complicated because there are "Steps"
between the BillOfMaterial and BOMComponents like so:
BillOfMaterial ->> Step ->> BOMComponent
Think of the BillOfMaterial as a recipe to make a specific Part. In
"Step 1" you will use 5 different BOMComponents. Each Step has
attributes such as instructions, tools used, etc. Each BOMComponent
has attributes like quantity, unit of measure, etc as well as the
part.
Yes, that does complicate it.
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.
In this specific example, I'm adding the specified Part to a
Manufacturing Schedule and I need to know what subParts (using your
terminology) need to be scheduled in addition to the Part that was
ordered. The way I find the subParts that need to be scheduled is to
open the selected BillOfMaterial for the Part, drill down to the
components and step through them to see if they need to be scheduled
as well.
You mention "selected BillOfMaterials". What happens when some of the
sub-parts are also Manufactured parts? Does the user manually select
their BillOfMaterials too?
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.
Tell me how to do it right. I'm all ears.
Well, you went and complicated it. :-) The Visitor pattern
suggestion is a good one. It could be your processing, rather than
model, that needs a change.
Chuck
--
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]
