Object identity v. classes

Having toyed a little with as dynamic a language as Ruby, while also working with as static a language as Java in the daytime, I’ve been having these thoughts lately about something that I feel gets lost with strong typing (I do know that strong typing is required for a “network language” such as Java). It has something to do with the identity of objects.

An object’s identity is not its class. Well, in Java it often is, but in OOP in general it’s not true: an object’s identity is determined by which messages it responds to. If two objects that are instances of two completely different classes (whose only common superclass is the “root” class; the equivalent of java.lang.Object) but whose set of messages responded to are identical – they have the same identity.

I feel that with strong typing, subclassing has become the only way of expressing identity. With dynamic languages you would only create a superclass if two classes share functionality that could be said to represent a common abstraction. Say you have a Dog class and an Elephant class. Both these animals can eat stuff, but this doesn’t mean that you have to create an Animal superclass with an abstract eat() method. You would only do that if there were code to share among the two. In terms of object identity, though, on a higher level of abstraction, Dog and Elephant objects are identical, because they both respond to eat messages.

What’s the point of this reasoning? I’m not quite sure, but this thinking suggests to me that perhaps I should be using interfaces more in Java to express identity. The thing I feel is lost in all this is the notion that an object’s identity is the same as the class it’s an instance of. Somehow, it gets too centered around classes. You hear all this talk about how it’s about “finding the classes”, when it’s rather about “finding the identities”. Some identities are best expressed as class hierarchies, while for others the best choice is to use interfaces.

I don’t know … Perhaps these ideas will mature in the future. Please do send me feedback if you have something to say about this: peter@tesugen.com.