isKindOf: vs. isClassX methods

Andreas Raab Andreas.Raab at gmx.de
Wed Oct 10 22:08:01 UTC 2001


>   The use of "isKindOf:" may just start another religious war.

Actually I don't think so. Pretty much every person I have ever spoken to
agreed that isKindOf: is bad design and bad style. So there are really only
very few reasons for using it at all:

a) We're too lazy to implement isXYZ (I think in Squeak that's reason #1)

b) We think we shouldn't modify existing classes (there's something to be
said about that because it may lead to conflicts - but considering the
potential costs and complexity of using isKindOf: the argument almost never
holds)

c) We think that we're adding too many methods to class Object (again,
there's something to be said about that but then again, wer're adding a
single method, getting a clean design, and so the cost is very small)

d) We need a dynamic test along the lines of "var1 isKindOf: var2"  - this
is a design flaw because obviously some third party is doing a decision
based on two variables which should be a responsibility of either party;
e.g., "var1 doSomeServiceWith: var2" which could - based on the class of the
actual receiver - invoke the appropriate method on the other end (like in
double-dispatching)

e) We need a way of assuring certain implementation details from the outside
(e.g., perform an action based on certain implementation properties rather
than the interface of the object - an example could be a parameter passed to
a primitive which expects exactly one type of object). That's a design flaw
too because we could equally well implement a service in that object's class
(and all other possible implementors) which does the right thing.

Thus I agree that in an ideal world we'd never use #isKindOf: - but in the
real world we do for a variety of reasons (some better, some worse ;-)

Cheers,
  - Andreas





More information about the Squeak-dev mailing list