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: David Avendasora <email@hidden>
- Date: Tue, 8 Apr 2008 12:27:01 -0400
Kieran,
"Hmm. Your ideas are intriguing to me and I wish to subscribe to your
newsletter."
I'm going to take a serious look at using this in the future as I can
see adding other classes and being able to morph from one behavior to
another could be helpful as well.
Thanks for the heads up!
Dave
On Apr 8, 2008, at 9:32 AM, Kieran Kelleher wrote:
An alternative way to handle this is to use the Strategy design
pattern and just have one Entity ... Part.
You would then create a PartBehaviour interface that encapsulates
all the things that vary among the various parts. It would give you
great flexibility to easily (easier than adding/maintaining another
entity to the eomodel inheritance hierarchy IMHO) add other kinds of
parts too such as SubassemblyPart, FinishedPart, ConsumablePart, etc.
A few years ago I had an inheritance hierarchy that was getting
painful (No Fun) to maintain as the system evolved and new
requirements had to be implemented ..... I collapsed the inheritance
hierarchy into one Entity and implemented the Strategy design
pattern and this has served me very well (even Fun to add features).
Switching from an inheritance hierarchy to Strategy design pattern
is very easy if you are already using Single table inheritance....
in fact IIRC, there is no database schema changes required at all.
The downside is that *every* Part has *all* attributes .......
however the approriate answer is returned when a Part is sent a
message .... so if asked for an attribute that does not make sense
for it to have, then it would return null or an empty array in the
case of a to-many.
The advantage of Strategy design pattern is that each entity can
have any subset of the total attributes, even overlapping subsets
without a thought or a care as to inheritance layers and overriding
logic of subclasses.
Of course Stratagy d.p. is not a panacea ..... sometimes it just
works better where inheritance design is becoming No Fun to deal
with, which often happens down the road as requirements change/
evolve :-)
However, if you are under pressure to Just Fix It right now, then
Chuck's solution might be easiest and quickest. If you find the
inheritance archtecture of Parts is hurting your ability to easily
add Real World business logic, then check out the Strategy design
pattern (Head First patterns book ... the first one described IIRC)
Regards, Kieran
On Apr 7, 2008, at 4:03 PM, David Avendasora 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
_______________________________________________
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