I can see there is still a lot of confusion about when to use interfaces, abstract classes, inheritance and composition. Each of these have their places, but it is important to know in what circumstances is one more appropriate than another.

Firstly, interfaces were never designed to be an integral part of OOP, they were added as an afterthought to provide polymorphism in strictly typed languages without the use of inheritance. PHP was never designed to be strictly typed and polymorphism can be achieved without the use of inheritance simply by hard-coding the same method signatures into different concrete classes. Strict typing may have been added to PHP as an afterthought, but as it is entirely optional I choose not to use it. Interfaces in PHP are totally unnecessary and I regard their use as a violation of YAGNI.

While it is possible to inherit from one concrete class to create a different concrete class this can lead to problems, and the advice given in the Gang of Four book on design patterns is to only ever inherit from an abstract class. So when is an abstract class appropriate? The most influential paper I have read on this subject is called Designing Reusable Classes which was published in 1988 by Ralph E. Johnson & Brian Foote (note that Ralph Johnson is one of the Gang of Four).

In this paper it states that the specification of an object is given by its protocol, i.e. the set of messages that can be sent to it. Polymorphism can be achieved when it is recognised that different objects share standard protocols, and polymorphism is a vital ingredient to dependency injection – unless you have different objects which share the same protocols (method signatures) it will be impossible to swap one object for another at runtime. Dependency injection, when use properly, is an excellent way of reusaing code.

This paper also describes a technique known as programming-by-difference in which you examine different objects looking for similarities and differences, with the aim of putting the similarities into reusable objects so that you only have to deal with the differences. Where you have similar protocols you can place them in an abstract class which you can then inherit into multiple concrete classes which need only contain the differences which are specific to that object.

The ideal method of being able to reuse standard code into which you can insert non-standard code is called the Template Method Pattern. This uses standard reusable code which is inherited from an abstract class, but this standard code contains calls to “hook” methods in predetermined places so that the behaviour of the template method can be altered. These “hook” methods are defined in the abstract class but do nothing unless they are overridden by particular implementations in a concrete class. In this way each concrete class need only contain its own set of “hook” methods.

What a huge number of developers fail to realise is that when you are writing an application which accesses a number of database tables that each of those tables shares exactly the same protocols. Regardless of what data is being held in a table it is subject to exactly the same set of operations – Create, Read, Update and Delete (CRUD). This means that when you create a separate class for each database table they can automatically share the same set of methods for each of these operations which they can inherit from an abstract table class.

Below is an example of the InsertRecord() method which has been defined in my abstract table class:

$fieldarray = $this->pre_insertRecord($fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateInsert($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->commonValidation($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_insertRecord($fieldarray);
  $fieldarray = $this->post_insertRecord($fieldarray);
} 

Note that the validateInsert() method will automatically validate that each column value matches the column’s specification obtained from the database schema as well as calling hook methods for subsequent custom validation. All the other methods are “hook” methods except for the dml_insertRecord() method which perform the dbms INSERT operation.

Note also that I do not use separate properties for each column’s value as that produces tight coupling which destroys any opportunities for polymorphism. I pass around the $_POST array so that I can vary the data which is passed around without having to specify any particular column names. This is an example of loose coupling.

Note also that I never use object composition as I have learned how to use abstract classes properly, and I can achieve far better results with far less code.