3

I have seen the term "common interface" used a lot while reading books about OOP.

For example, the book The Essence of Object-Oriented Programming with Java and UML says the following:

Abstract classes usually define a common interface for subclasses by specifying methods that all subclasses must override and define


My understanding of the term "common interface" is the following:

Assume that we have a superclass (or an interface or an abstract class) called Animal and two subclasses called Dog and Cat, and Animal have two virtual methods called makeSound() and move().

Now the common interface would be composed of two methods which are Animal.makeSound() and Animal.move().

Assume that we have the following code:

Animal animal1 = new Dog();
animal1.makeSound();
animal1.move();

animal1 = new Cat();
animal1.makeSound();
animal1.move();

The explanation of the above code is the following:

Animal animal1 = new Dog() creates an Animal common interface and associate a Dog object with it:

enter image description here

animal1.makeSound() sends an Animal.makeSound() message to the common interface, and then the common interface sends a Dog.makeSound() message to the Dog object:

enter image description here

Same thing happens in the case of animal1.move() (which is the Animal.move() message is sent to the common interface, etc.).

animal1 = new Cat() removes the Dog object from the common interface, and associate a Cat object with the common interface:

enter image description here

animal1.makeSound() sends an Animal.makeSound() message to the common interface, and then the common interface sends a Cat.makeSound() message to the Cat object:

enter image description here

Same thing happens in the case of animal1.move() (which is the Animal.move() message is sent to the common interface, etc.).

Am I correct in my understanding?


Edit:

The Animal common interface in my diagram is not an object, but rather it is the virtual methods (or I guess I can call them the "message handlers") that receive the Animal.makeSound() and Animal.move() messages and then send the appropriate messages to the associated subclass object.

  • The Animal common interface in my diagram is not an object, but rather it is the virtual methods (or I guess I can call them the "message handlers") that receive the Animal.makeSound() and Animal.move() messages and then send the appropriate messages to the associated subclass object. Does this make my diagram correct now? Due to this comment, I considered removing my answer because I find a meaningful difference between the question What does “common interface” mean in OOP? and Ho are interface calls managed in runtime by the JVM. – Laiv Jun 19 at 13:26
  • That said, I would ask you to edit the question so it's clear what of the two things you are asking about. T think the answers bellow illustrate what "common interface" use to mean for many of us. If that's not the point of the question and you are only interested in how Java manage this internally, I think you might be interested in the following question – Laiv Jun 19 at 13:31
  • Looks like the link I shared might help you out to find the answer. Note that the link in the checked answer is in reference to OpenJDK. I assume the answer may differ from JVM to JVM – Laiv Jun 19 at 13:38
8

An interface is not a separate entity or object - an interface is just a characteristic (or set of characteristics) of an object. Specifically characteristics which describe how to use/interact with an object.

The term "common interface" is a way of describing the fact that Dog and Cat happen to share some of the same characteristics, and that these shared characteristics can allow these to be used interchangeably in code. (provided that there are no Dog-specific or Cat-specific characteristics involved).

To shift to another very simple example, most programming languages have data types called int and double - these nearly always share a common interface because they can both be used with the 'BODMAS' arithmetic operators despite the fact that integer representation and floating-point representation work very differently to each other.

In the given example of animal1.move(), animal1 is just a plain variable (i.e. a name) - it has no behaviour of its own. It's a simple programming language construct which acts as a name/alias for an object, and which enables a programmer to write code that uses/interacts with an object

  • if the animal1 variable is an alias to a Dog object, then animal1.move() sends a move() message directly to that Dog object.
  • if the animal1 variable is an alias to a Cat object, then animal1.move() sends a move() message directly to that Cat object.

A better analogy for the term interface could be when thinking about how a human interacts with a car while they are sitting in the driver's seat. From a driver's point of view, all cars have a common interface for someone driving the car:

  • A steering wheel
  • Accelerator pedal
  • Brake pedal
  • Hazard Lights
  • Indicators

These are all characteristics of any car, however, any individual car will always have their own Steering wheel, pedals, lights, etc.

The term "common interface" is conceptual rather than physical (the interface isn't separate from the object, it is part of the object) - the common interface of a car means that any qualified driver of one car is able to seamlessly take control over any other car without needing to adapt their understanding of how to drive. The rules and actions involved in driving one car do not change when switching to a different car.

| improve this answer | |
  • Strictly speaking, you wouldn't even need an object to have an interface, if you look outside OOP. Still, a good explanation. – Deduplicator Jun 19 at 18:20
  • You said: "if the animal1 variable is an alias to a Dog object, then animal1.move() sends a move() message directly to that Dog object" and "if the animal1 variable is an alias to a Cat object, then animal1.move() sends a move() message directly to that Cat object", by "move() message", do you mean Animal.move() message? and so the whole point of Dog and Cat implementing an interface (or overriding the virtual methods of a superclass) is to be able to respond to the same messages (in this case Animal.makeSound and Animal.move())? – Tom Jun 19 at 20:48
  • @Tom Not quite; there isn't an Animal.move() message, and Animal isn't an object. But more importantly, Animal exists to describe the how an object can be used - it doesn't affect what Dog or Cat can do. It just allows those objects to be used interchangeably. The message is simply just move() (i.e. the thing on the right-hand-side of the dot .). Dog and Cat objects could still handle move() without the interface, but without a common interface, sending a message would require explicit knowledge of whether the object is a Dog or Cat. – Ben Cottrell Jun 20 at 8:31
  • "The message is simply just move()" do you mean that both Cat and Dog objects can receive the same message move()? because I remember reading that even though objects of different types (for example: Cat and Dog objects) can receive some message, like move() (for example: cat1.move() and dog1.move()), in reality the move() message that is being sent to the Cat objects is different from the move() message that is being sent to the Dog objects, it's just that both messages have the same name (which is move()). – Tom Jun 20 at 22:20
  • @Tom I'm not sure of the context of what you read so I can't comment on what that means. However, the point of a common interface is for Cat and Dog objects to be used interchangeably, which can only work if both are capable of receiving exactly the same message. To put it another way, if they were different messages, then the interface wouldn't be common, and the code which uses those objects would need to select a different message to send depending upon the target object's type - e.g. if animal1 is Dog or if animal1 is Cat. – Ben Cottrell Jun 22 at 17:21
0

Conceptually Correct - at a very High Level.

Technically incorrect though. The message isn't sent to an Interface and then on forwarded to the instance.

What actually happens is that Animal establishes a protocol of behaviours. This protocol is filled in by implementations such as Dog, and this protocol is then used by callers to find the correct behaviour for the given implementation.

As such Dog implements its version of makeSound to make a barking noise. It publishes this behaviour as appropriate to the Animal protocol so that users of Animal can find this barking version of makeSound.

When the caller holding Animal a then makes a call a.makeSound(). The caller knowing about Animals follows the protocol and gets the behaviour to call. In this case its Dog.makeSound(). It then calls this Dog implementation directly.

| improve this answer | |
  • Interesting. But since protocols are not the most obvious and unambiguous concept of OOP, doesn't this answer risk to transform the interrogations PO has about interfaces to interrogations about protocols? – Christophe Jun 19 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.