Re: Best Way(R) to test for existence of a relationship
Re: Best Way(R) to test for existence of a relationship
- Subject: Re: Best Way(R) to test for existence of a relationship
- From: "Michael Bushkov" <email@hidden>
- Date: Tue, 8 Apr 2008 12:29:46 +0400
Just my 2 cents to the discussion )
If we consider the object model to be correct then the task of
traversing the array with 2 types of objects seems to be ideal for the
Visitor pattern. Am I missing something?
On 4/8/08, David Avendasora <email@hidden> wrote:
> Unfortunately, no. There's _lots_ of differences. There are a number of
> attributes that they share, but they each have completely different business
> logic for deriving those values, and they each have attributes that are
> unique to themselves that would make no sense to have on the other.
>
> As uncommon as it is to actually need inheritance in the Model, the amount
> of work I would have to do to not use it would far exceed the amount of work
> I have to do to use it.
>
> Believe me, I'm not using it just because it is a cool OO concept. Not that
> I don't do that in other places in my app - just not here. :-)
>
> Dave
>
>
> On Apr 7, 2008, at 3:18 PM, Alexander Spohr wrote:
>
>
> > 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
>
--
With best regards,
Michael Bushkov
_______________________________________________
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