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. 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).
ms
_______________________________________________
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]
