Re: Best Way® to test for existence of a relationship
Re: Best Way® to test for existence of a relationship
- Subject: Re: Best Way® to test for existence of a relationship
- From: Alexander Spohr <email@hidden>
- Date: Mon, 7 Apr 2008 21:18:22 +0200
What are the other differences between RawMaterial and ManufacturedPart?
Wouldn’t it be enough to just flag the RawMaterial ones as such and
just have one class for both?
atze
Am 07.04.2008 um 18:02 schrieb David Avendasora:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
---
Alexander Spohr
Freeport & Soliversum
Fax: +49 40 303 757 99
Web: http://www.freeport.de/
Box: http://dropbox.letsfile.com/02145299-4347-4671-aab9-1d3004eac51d
---
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden