• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Best Way® to test for existence of a relationship
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best Way® to test for existence of a relationship


  • Subject: Re: Best Way® to test for existence of a relationship
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 7 Apr 2008 10:23:43 -0700


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      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Best Way® to test for existence of a relationship
      • From: David Avendasora <email@hidden>
References: 
 >Best Way® to test for existence of a relationship (From: David Avendasora <email@hidden>)
 >Re: Best Way® to test for existence of a relationsh ip (From: Bob Stuart <email@hidden>)
 >Re: Best Way® to test for existence of a relationsh ip (From: Chuck Hill <email@hidden>)
 >Re: Best Way® to test for existence of a relationsh ip (From: Mike Schrag <email@hidden>)
 >Re: Best Way® to test for existence of a relationsh ip (From: Chuck Hill <email@hidden>)
 >Re: Best Way® to test for existence of a relationship (From: David Avendasora <email@hidden>)

  • Prev by Date: RE: File name issue
  • Next by Date: Development vs Deployment Error
  • Previous by thread: Re: Best Way® to test for existence of a relationship
  • Next by thread: Re: Best Way® to test for existence of a relationship
  • Index(es):
    • Date
    • Thread