RE: Back to Basics - Three or Four OOP Pillars?

Introduction

What is abstraction?

Functional Abstraction results in shared methods

Data Abstraction results in shared properties

A wrong definition for Abstraction

A wrong definition for Encapsulation

Conclusion

Comments

Introduction

I have been using PHP as my primary language now for over 20 years, starting with version 4, and by making optimal use of its OO capabilities I have single-handedly produced a multi-award winning framework called RADICORE which has been used as the foundation of a multi-module ERP package called GM-X Application Suite. Because I learned so much from online tutorials I felt the need to give back to the community by contributing articles of my own to document how I went about designing and building my framework. While the internet is full of valuable resources, because there is no barrier as to who can post what, there is also a surprising amount of bullsh*t and mis-information. This is my reaction to one of those articles.

Some while ago I came across Back to Basics ... Three or Four OOP Pillars? where the opening statement was:

A New Addition to the OOP Pillar Family? -- Data Abstraction

I disagree with this statement as there is no fourth pillar to OOP, there are only three - Encapsulation, Inheritance and Polymorphism. I say this because when you are identifying the characteristics of a new programming paradigm you should only mention those things which are unique to that paradigm, those things which set it aside from previous paradigms. Before switching to PHP I spent 20 years with other non-OO languages, including 16 years with COBOL which was the most widely used procedural language of its day. I therefore feel that I am more than qualified to comment on the differences between procedural and object oriented languages.

When I began my foray into OOP the first thing I did was look for a description as a starting point. The best description I found went as follows:

Object Oriented Programming is programming which is oriented around objects, thus taking advantage of Encapsulation, Inheritance and Polymorphism to increase code reuse and decrease code maintenance.

That is why I have concentrated my work around those three factors, and only those three factors. Anything which does not contribute to the production of more reusable code which requires less maintenance I consign to the rubbish bin (or flush down the toilet).

As far as I am concerned abstraction is not one of the defining characteristics of OOP as it existed as a mental process long before OOP came into being.

What is abstraction?

The PHP manual did not mention this thing called "abstraction", so I was unaware of its significance for many years. Then I started coming across articles which claimed that abstraction was the fourth pillar of OOP, but I could find no adequate description of why this was so. It appeared that far too many clueless newbies were confused over the true meaning of encapsulation, which had to be debunked in articles such as Abstraction, Encapsulation, and Information Hiding by Edward V. Berard of The Object Agency. Abstraction and encapsulation do not mean the same thing, there are entirely different. The only tenuous connection is that the result of performing an abstraction may be an abstract class which holds code which can be reused/shared by any number of concrete classes. Encapsulation can be demonstrated in code, but as abstraction is a mental process it cannot. This is why I say that that are not the same.

The only worthwhile definition of abstraction I have ever found is contained within Designing Reusable Classes which was published in 1988 by Ralph E. Johnson & Brian Foote. Although I did not discover the existence of this document until many years after I had written my framework, which was due to the fact that very few other people had provided references to this article, I was surprised to see that I had intuitively been implementing this technique which they describe as programming-by-difference. This requires that after you have written the code for several entities you examine that code looking for similarities and differences. You then find a way to put the similarities into a reusable module and confine the differences into a series of unique modules. As I develop nothing but database applications where each table is a separate entity I use an abstract table class for the similarities which is then inherited by every concrete table class which contains nothing but the differences. I have written more on this topic in The meaning of "abstraction".

Functional Abstraction results in shared methods

Every entity in the business layer of a database application is a table, and every database developer should know that the only operations which can be performed on a database table are Create, Read, Update and Delete (CRUD). It does not matter that each table holds totally different data, each table is subject to exactly the same operations. I have created methods for each of these operations and placed then into an abstract class, as shown in Common Table Methods below:

$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);
}

$fieldarray = $this->pre_updateRecord(fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateUpdate($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->commonValidation($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_updateRecord($fieldarray);
  $fieldarray = $this->post_updateRecord($fieldarray);
}

$fieldarray = $this->pre_deleteRecord(fieldarray);
if (empty($this->errors) {
  $fieldarray = $this->validateDelete($fieldarray);
}
if (empty($this->errors) {
  $fieldarray = $this->dml_deleteRecord($fieldarray);
  $fieldarray = $this->post_deleteRecord($fieldarray);
}

$where = $this->pre_getData($where);
$fieldarray = $this->dml_getData($where);
$fieldarray = $this->post_getData($fieldarray);

Here the methods called externally are the ones which are called from the Controller while the methods called internally are called only from within the abstract table class which is inherited by every Model. Each external method then acts as a wrapper for a group of internal methods. Notice that before and after each database operation, which has the "dml_" prefix, there are pairs of "pre_" and "post_" methods. These will contain calls to "hook" methods to enable each subclass to provide custom logic.

More information can be found in A Development Infrastructure for PHP.

Data Abstraction results in shared properties

This is where the clueless newbies fall short as they cannot think of any properties which are common to all database tables. It is quite obvious that the application data held in the table's columns is unique, so what data is possibly shared? The answer is the metadata which is stored in the INFORMATION_SCHEMA within the database itself. To cater for this data I have the following common table properties within the abstract table class.

These placeholders are empty within the abstract superclass, but when a concrete subclass is instantiated they are loaded with values from a separate <tablename>.dict.inc file which is exported from the Data Dictionary.

A wrong definition for Abstraction

The erroneous definition I found for abstraction in Back to Basics ... Three or Four OOP Pillars? goes like this:

Data Abstraction - the Encapsulation of State in Data Transfer Objects Using Composites and Aggregates DTOs

This is wrong for the following reasons:

• As I have mentioned earlier, OOP only has three pillars - Encapsulation, Inheritance and Polymorphism - not four. Abstraction is a mental process which existed years before OOP came into being, so it cannot be described as a defining characteristic of OOP.
• The process of abstraction, whether it be functional abstraction or data abstraction, must result in things which are shared by multiple entities, and application data simply does not fall into this category. Application data belongs in each concrete class, while table metadata belongs in the abstract class.
• A Data Transfer Object (DTO), which is also known as an anemic domain model is considered to be an anti-pattern as it is contrary to the basic idea of object-oriented designing; which is to combine data and process together. I will not waste my time with such objects for the simple reason that when implementing the 3-Tier Architecture with PHP all three layers pass the application data around in an array, and I do not have to convert it into any other format, which includes putting each piece of data into its own class property, in order to view and manipulate it. Converting that array into a DTO does nothing but waste keystrokes, which I consider to be a violation of YAGNI.

A wrong definition for Encapsulation

To make matters even worse the clueless newbie even has a wrong definition for encapsulation:

Encapsulation - Details Required to Return a Result from a Class Method should be Hidden from the Calling Method

What on earth made this clueless newbie come up with THAT crazy definition? As explained here the TRUE definition is as follows:

The act of placing data and the operations that perform on that data in the same class. The class then becomes the 'capsule' or container for the data and operations. This binds together the data and functions that manipulate the data.

As mentioned earlier, the defining characteristics of OOP can only include those things which did not exist before the advent of OOP. This means that the following statements are invalid:

• Encapsulation means data hiding.
• Encapsulation means implementation hiding.

How can I possibly say such a thing? Because calling a method on an object in an OO program is exactly the same as calling a function/subroutine in a procedural program. I spent 16 years programming in COBOL, so I was used to writing statements such as:

CALL <procedure> USING <input-argument>
                 GIVING <output-argument> 

Each of these arguments is a record, also known as a composite data type or a struct in the C programming language.

The following things are blindingly obvious to me:

1. The input argument is not hidden. All the data items are completely visible.
2. The output argument is not hidden. All the data items are completely visible.
3. The procedure name is specified, but the code behind that name, i.e. the implementation, is hidden. The procedure name should give some indication of what it does, but how it does it is completely invisible to the calling program.
4. If the implementation uses variables which are constructed within that procedure they are destroyed when that procedure terminates, and there is no way for the calling program to either adjust or examine those variables.

As these features existed way before OOP came into being it is my opinion that they cannot be described as defining characteristics of OOP. They were not created especially for OOP, instead they can be said to be inherited by OOP.

Conclusion

It is articles like Back to Basics ... Three or Four OOP Pillars?, written by clueless newbies, which fill the internet with mis-information which, instead of adding to the pool of knowledge, end up by muddying the waters and leading new programmers up the wrong path. Instead of producing rock star programmers they are producing rocks-in-the-head programmers. This fills me with despair. All I can do is attack this mountain of mis-information with logic, but it appears that far too many people have been brainwashed into following dogmatism instead of pragmatism that they are immune to logical arguments.

Here endeth the lesson. Don't applaud, just throw money.