On Apr 7, 2008, at 8:45 AM, Mike Schrag wrote:
Using instanceof on a member of an inheritance hierarchy is a bad
code smell. It is the code's ways of telling you that your design
is wrong. IMO.
I was going to say in my original that instanceof is a code smell,
also, actually, but we disagree on the level of ugliness :) You're
just cheating -- avoiding an instanceof by mucking up your object
model doesn't fix the problem, it just hides it, and makes your
object model more confusing at the same time. If there are classes
in your hierarchy that don't implement the method, it's not part of
the interface. This implies to me that the original design is
wrong, unless it really is the case that it's reasonable to ask the
other part types their billsOfMaterials, and they just don't have any.
Yes, that is what I was assuming by his trying to call billOfMaterials
on a collection of Parts.
But given the original description, I'm assuming the model is right
and that's not the case. Bob's suggestion of declaring an
additional interface that defines that method definitely seems
better, but it doesn't clean up the instanceof check. Even better
would be to construct your original fetch to only fetch the objects
that this check actually applies to (though as I think about it,
this is really just a variation on instanceof -- you push the
instanceof, conceptually, into the fetch instead of in Java, but if
the model doesn't allow incorrect traversal, that seems better to me).
If the original design is correct, then somehow selecting the
appropriate subset of objects to iterate over seems like the correct
solution. If there is more than one disjoint class that has
billOfMaterials, that again suggests a design flaw.
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]