The origin of Object Interface

Introduction

The origin of interfaces

Comments

Introduction

I developed my code base using PHP 4, which made no mention of these things called object interfaces, so I learned to program without them. Even so I managed to create code which contained manifestations of Encapsulation, Inheritance and Polymorphism, and this code is still going strong after 20+ years, and has been upgraded to work with versions 5, 7 and 8.

Objects interfaces were added to PHP 5 for no good reason other than other OO languages have interfaces, so PHP should have them as well. The way they were described made them out to be the best thing since sliced bread, but the more I looked at them the more I realised that, in PHP at least, they are as useless as a chocolate teapot. Some programmers claimed that they were a fundamental part of object-oriented programming (OOP), which just shows that they do not understand what the word fundamental actually means. The truly fundamental characteristics of OOP are nothing more than Encapsulation, Inheritance and Polymorphism - everything else is nothing more than an add-on.

I tried researching when and why object interfaces appeared on the scene, but all I could find were statements along the lines of interfaces are great, here is why you should use them. Eventually I found an article which explained that interfaces were created in order to support subtyping which is supposed to be different from subclassing.

The origin of interfaces

The ability to inherit from a class to create a number of subclasses has been universal (as far as I can tell) across all class-based OO languages. As well as being able to share code, this has always been the standard way of providing polymorphism as any subclass has always been able to override a method in the superclass. So where on earth did the idea of subclassing is for sharing code, subtyping is for polymorphism originate? Why are the two different? Why was this restriction not copied into PHP where subclasses can be used for both code sharing and polymorphism? Why are subtypes not mentioned in the PHP manual?

Eventually I found a clue in Polymorphism and Inheritance are Independent of Each Other from accelerateddevelopment.com:

Flexible programs focus on polymorphism and not inheritance. Some languages focus on static type checking (C++, Java, C#) which links the concepts and reduces polymorphic opportunities. Languages that separate the concepts can allow you to focus on polymorphism and create more robust code. PHP, JavaScript, Python, Ruby and VB.NET do not have typed variables and defer type checking to runtime. Is the value of static type checking worth giving up the power of pure polymorphism at runtime?

It would appear that the ability to provide polymorphism on certain method calls but not others was the product of minds that were so obsessed with static type checking that they decided that polymorphism should only be provided for objects of the same type, so they invented a mechanism for giving different objects the same type. That mechanism involved the use of virtual functions which are known as abstract methods in other languages. This led to a split in the way method calls were handled at run time:

• Subclasses are created by extending a class, which is a collection of non-abstract methods. Calling one of these methods is resolved using static dispatch which means that the target method is resolved at compile time. This means that the method cannot be overridden in a derived class at run time, so the implementation in the superclass cannot be changed.
• Subtypes are created by implementing an interface, which is a collection of abstract methods. Calling one of these methods is resolved using dynamic dispatch which means that the target method is resolved at run time. Methods in an interface do not have an implementation, so they must be overridden in the derived class.

This gave rise to the following rule which many uneducated programmers erroneously think applies to all OO languages:

Subclassing is for code sharing while subtyping is for polymorphism.

Why was such an artificial restriction introduced in the first place? Once the code for dynamic dispatch had been written why could that not be applied to all method calls and not just some of them? Other languages, such as those mentioned above, managed to do this, so it was a reasonable step to take.

This artificial restriction does not apply to PHP which operates as follows:

• It does not have a compilation phase, therefore all method calls, irrespective of how the methods were created, are resolved at run time using dynamic dispatch.
• An abstract class is constructed in the same way as a non-abstract class except that it cannot be instantiated into an object, it can only be extended into a number of concrete subclasses.
• Each subclass must therefore contain code which turns an unknown abstract class into a specific concrete (non-abstract) class. In the RADICORE framework this is done in the class constructor.
• If a class contains an abstract method then all the methods in it must be abstract.
• It is erroneous to believe that an abstract class can only contain abstract methods otherwise it would be no different from an interface. A method in an abstract class can contain an implementation that will be inherited, and it may be overridden in any subclass. This is the basis on which the Template Method Pattern was built.

This is the description for a Virtual Function I found in wikipedia:

In object-oriented programming such as is often used in C++ and Object Pascal, a virtual function or virtual method is an inheritable and overridable function or method that is dispatched dynamically. Virtual functions are an important part of (runtime) polymorphism in object-oriented programming (OOP). They allow for the execution of target functions that were not precisely identified at compile time.

Virtual functions are resolved "late". If the function in question is "virtual" in the base class, the most-derived class's implementation of the function is called according to the actual type of the object referred to, regardless of the declared type of the pointer or reference. If it is not "virtual", the method is resolved "early" and selected according to the declared type of the pointer or reference.

A virtual function/method is one that does not provide any implementation when it is defined so it must be overridden in any derived class, thus providing polymorphism where the actual implementation is resolved at run time through the mechanism known as dynamic dispatch. These virtual functions (which are known as abstract methods in PHP) can be grouped together in collections known as object interfaces. Interfaces can be shared by derived classes using the implements keyword. A derived class can implement any number of interfaces while it can only extend a single superclass.

I can do everything I want with an abstract class, which is more than I could achieve with an interface. This is why interfaces will NEVER appear in my code base.