Skip to content

On Polymorphism

So, in an effort to broaden my horizons, and following the maxim “learn a new language every year” (and theorising here that Classical Latin does not count), I decided that I will learn the basics of Objective-C. After I’ve used a Mac for many years and it’s about time I learned to program the thing in its natural programming language.

Reading the development docs that Apple provide for Objective-c I’ve twice come across this definition of Polymorphism, or something like it;

… two objects can respond differently to the same message. For example, each kind of object that receives a display message could display itself in a unique way. A Circle and a Rectangle would respond differently to identical instructions to track the cursor.

This feature, referred to as polymorphism, plays a significant role in the design of object-oriented programs. Together with dynamic binding, it permits you to write code that might apply to any number of different kinds of objects, without you having to choose at the time you write the code what kinds of objects they might be. They might even be objects that will be developed later, by other programmers working on other projects. If you write code that sends a display message to an id variable, any object that has a display method is a potential receiver.

Well, OK, at a basic level, I guess. It’s saying that a method, e.g. draw() will behave differently in its implementation on type Circle to type Rectangle. And that perhaps a different programmer could supply a different Shape object that has another different draw() method.

But am I alone in thinking that while the above actually may be strictly subtype polymorphism, it’s not really the interesting point of its programatically expressive power. The above just sounds like inheritance combined with method overriding. Polymorphism isn’t just inheritance! Just to exclude things like parametric polymorphism (aka generics), and method overloadingfor a moment.

For me; polymorphism at its most basic (i.e. subtype polymorphism), derives from something like this;

interface Circle extends Drawable, TwoD, HasCanvas {
  // from Drawable
  void draw();
  // from TwoD
  HeightWidth getDimensions();
  // from HasCanvas
  Canvas getCanvas();
  void setCanvas(Canvas canvas);
interface Pencil extends DrawingInstrument, SharpenIt {
  void draw(Drawable thingToDraw);
  void surfaceToDraw(HasCanvas hasCanvas);
  void sharpenIt();

For me, the real key to polymorphism is that a single type can have multiple interfaces, i.e. that the Circle above, can in one circumstance, look like a ‘Drawable’, and in another, a ‘HasCanvas’, and not that there might be multiple implementation of either ‘Drawable’ and ‘HasCanvas’, etc … which just describes inheritance, if you ask me.

Tell me I’m wrong. Maybe its just because the Objective-C document is trying to slowly introduce these concepts to people only used to C?


  1. The example given in the Objective-C doco is the classic textbook example of polymorphism – you can have many different objects fit the shape that you want. e.g “I have this round hole – how many of these pegs can fit in to it?”

    This is the definition I was given back when I first learnt OO, reading Grady Booch’s book in uni.

    There’s no implication of inheritance here, BTW; Circle and Rectangle can be completely different objects with no inheritance, but merely responding to the same message – that is to say, implementing the same interface.

    The concept of _multiple_ interfaces is a layer added to OO by the use of typed languages. All an interface is is a way of saying “Hey, I support these messages”, which is handy with static typing but not anything to do with OO, as such.

    Objective-C has interfaces, but it’s just a hint to the compiler, not a core part of the language, and is easily bypassed.

    Thursday, April 12, 2012 at 23:29 | Permalink
  2. Scot Mcphee wrote:

    “There’s no implication of inheritance here, BTW; Circle and Rectangle can be completely different objects with no inheritance, but merely responding to the same message – that is to say, implementing the same interface.”

    But ‘implementing the same interface’ is a form of inheritance (i.e. it satisfies an is-A relationship) for all but the most weakly ‘duck typed’ of languages.

    And Obj-C has no real interfaces? Ughhh. I always start with the interfaces.

    Friday, April 13, 2012 at 07:56 | Permalink
  3. Objective-C has interfaces. But you can easily call any method on anything which descends from NSObject, without needing to cast to a particular interface – the interface is not a constraint to the client.

    (You could do the same thing in Java, but it’s painful and requires reflection)

    Interfaces still remain a good way to design your objects, of course.

    Friday, April 13, 2012 at 17:34 | Permalink