Is OOP Fever in PHP community too much ?
As you probably know, OOP stands for Object Oriented Progamming, and it is widely used as a practice, even as a philosophy in many programming languages, PHP included. And object oriented php is hot. So hot that, to be taken seriously as a PHP developer, you have to know it, use it, preach it, and propagate it.
But, as with everything taken to extreme, this kind of exaggerated approach has its major downsides. But why ? Lets look at what OOP is, and how it reflects on PHP programming world first, and then examine how it
What is Object Oriented Programming in a nutshell ?
Basically, oop can represent conceptual or real world objects which have interdependent properties. Imagine a circle – its area, circumference changes as its radius changes. So, using an object to represent a radius is the best way to implement and process a circle in a program – when the object’s radius changes, its circumference, surface area automatically changes accordingyl.
All fine and dandy. But, for majority of PHP applications we dont have that kind of data
In reality, where PHP code is used, you have little need for such ‘real’ objects. Most of the PHP code that runs applications (aside from a respectable number of gaming apps) are applications/websites that process linear data. Linear data as in shopping records, customer records, member preferences, forum posts, 3rd party api details, emails and similar.
Of course, information technology is not a limited world, and there are endless numbers and varieties of applications in that world. However, as can easily be seen from major websites, web applications/software that are in widespread use, ranging from major php using websites to commonly utilized software like wordpress, phpbb, vbulletin and similar – not to mention many facebook apps – reality evaluates to more linear data than true object data.
That doesnt differ much in corporate sphere. Imagine a medium to large size corporation, and imagine its i.t. department working on an intranet application to facilitate easier record keeping and accounting. Aside from a number of tax relationships, the majority of the data would be linear, static data which is not interdependent – revenues, profits, costs, dates, vendors, suppliers and more.
So then, what is the true reason OOP is so big in PHP, and why we are using it ?
The answer evaluates to different, peripheral properties of OOP – it is not the true nature of representing an object that is useful for php, but its peripherals like encapsulation, modularity, and the like.
For example, encapsulation provides us with the possibility of keeping a set of variables, their values, and the methods (functions) that may operate on them in a distinct, isolated, portable component – an object. For example, in an ecommerce application software, an order can be represented an object, and therefore that order, all values, variables, and all methods you need to operate in that object, may be included, moved, ported anywhere within the code and used as a separate unit. Which, inevitably creates and enforces modularity – the modular nature of the code. And modularity in turn, provides us with the possibility of being able to use the code segments as modules, including, using, excluding them wherever necessary – which in turn makes creating different routines to accomplish different tasks with set of objects easier.
These are major pluses for using OOP in PHP applications. It goes to such an extent that, even an object code (class) which you have written a few years ago, can be included and used by another application you are programming in the present, and be utilized effectively by minor modifications. Or, totally different objects from totally different applications can work alongside each other without affecting each other and conflicting.
Then where does Object Oriented PHP go wrong ?
It goes very wrong due to just a simple feature of human nature – fixation brought by zealotry. Which acts to limit the perspective of the individual and the masses into a narrow window through which they perceive and understand whatever subject they are dealing with, and causes them to react only in the boundaries of that narrow window. Not limited to programming, or information technology in general, of course – this is a phenomenon which afflicts all facets of human life ranging from choices we make while buying products to science and research.
But of course, this would be a too broad identification of the problem. To be precise it is much better to examine a number of individual situations on which this general phenomenon affects the perceptions and behavior of programmers/developers.
Overuse of objects in object oriented PHP
First reflection of this phenomenon is over use of objects due to intoxication by the concept. Due to over-preaching and over-advertisement of the OOP principles, the individuals in the community feels pressurized/conditioned to use object oriented programming more and more, even in situations in which OOP is flat out unnecessary. The tendency to represent ALL data as objects appears as such. Even if there is a simple piece of data, like a few fields’ worth of user preferences data coming out of a database, you may see it being represented as an object. Despite it can be passed around very easily as a simple array – associated or numeric.
When this phenomenon occurs, you may see the code produced by such developers end up getting over-cluttered by lots of objects flying around, turning the modularity and encapsulation eases oop provides, into a nightmarish mess of objects to be tracked, handled, and sorted. So, if we make an analogy that says objects are individual smurfs, this kind of code becomes the smurf village in which the smurfs are running haywire during an attack by Gargamel.
Funny analogy aside, this phenomenon leads to over complication and mess-up of the software code – which may eventually be need to dealt with by someone else, or by the very person who has coded that software himself/herself. And tidying up software is much harder than coding it from scratch.
Limiting knowledge and practice
In line with the earlier problem we examined, the second most visible reflection of this phenomenon ends up limiting the knowledge and its subsequent practice. Over-preaching, intoxication with the concept makes fledgling, even veteran developers to see everything through that viewport, and limits their perspective to the extent that they may even fail to learn/remember some basic features of PHP programming.
Imagine a simple case of a programmer which thinks that you need to create a new database object for every different database connection s/he wants to make and use. This programmer may end up having to change the entire code and sprinkle different database objects, instantiated and running independently of each other, doing the SAME thing, with only different databases. Of course, as you can understand, this is totally unnecessary if there isnt a specific requirement/necessity to do as such.
However, if the perspective of this developer was not overly limited by overpreaching, s/he would have learned, remembered that it is possible to keep different connections to different databases in the same database object’s variables :
Even more, multiple database result sets, their errors, and different related information also could be kept as such :
In these cases, $db->connections[‘connection1’] would behave exactly like how a variable $link which assumed the connection info from a database connection function returned, and $db->results[‘result1’] would behave exactly like a $result variable which was loaded with the return value of a database query function behaves.
All of which, could easily be operated upon by common methods in the same database object under hand, without introducing unnecessary clutter of objects into the code.
To much surprise, you may find people who fall into this category even in places like Stack Overflow.
Pigeonholing every piece of code into Objects
Not surprisingly, again in line with the earlier issues, another phenomenon manifests itself as trying to do everything through objects – including any piece of code. Such developers tend to shove any kind of small routine they are writing into this or that object, and call the method they created through that object – even codes which can be placed into a simple function which will be available and used globally. Or, in the extreme cases, simply procedural small routines which will never be used elsewhere in the code, or another application.
Lets face it – in eventual end, the basic core of programming is always procedural ; if you are going to do a search/replace on a string, there will be an initial state of that string, and there will be a later state of that string – one will follow the other, sequentially.
$string="Hi, im a string ! Change something in me !";
As you can see, in ultimate end, every piece of code is sequential. You cannot have operated on the string, before that string exists. Even if you have this string in an object as a variable which is tied to a method (automatically processing the string), the string will STILL be fed into the object variable (therefore assigned) first, and the method will operate on it to give its value in the object var. Philosophically, there will never be a case in which the string may be present in two states in the same variable at the same time.
Therefore, developers who are intoxicated/pigeonholed with the oop perspective may end up being inefficient and wasteful while programming, going out of their way to accomplish even simple tasks through shoving them in objects, and very often bloating and overcomplicating the objects that are used in their code.
This is a very harmful trait in the era of fast developing applications, agile programming and the competition any kind of individual, website, application or institution faces from each other.
If you are not fast enough, someone else does it
So then, what’s the solution ?
The solution, is, like many problems, actually very easy, but hard to implement. The solution in its core is, keeping a flexible mind, not pigeonholed, limited by any perspective, keeping zealotry and philosophy-worship out, and analyzing and solving problems and accomplishing tasks on an individual basis without approaching everything with the same bag of fixations.
The hardship of implementing this solution comes from a very detrimental aspect of human nature – identification. Humans identify themselves with many things outside their own consciousness – be it nationality, religion, tastes of music or any other imaginable external concept. Not surprisingly, we have the same kind of manifestation in information technology, in which people ascribe themselves to, and identify themselves with various technologies, languages, or philosophies or methods, and act as a collective group just like how a religious group behaves.
You may find people who are ascribing to a dominant philosophy try to exclude any other kind of approach, berate anyone who suggests anything else, and even try to silence those who criticize the obvious problems the over zealousness brings.
Zealotry is so strong a phenomenon that, you may find it affecting project management, long term planning, even hiring decisions. It is detrimental and damaging to any kind of community. As the science history shows us from the stories of ridiculed, and then vindicated science pioneers, zealotry can also cause mankind to lose time in realizing and implementing important developments which may benefit mankind at large, leave aside a small field.
Information Technology is no exception to this plague. You can easily find aged, veteran developers, industry veterans flaming each other in discussion threads, writing fiery articles against what and who they perceive to be the ‘heretics’, all around the internet. Unproductive. Limiting. Narrow minded.
Then, for the solution of this problem, and many similar problems, the first thing that needs to be done away with, is the zealotry. The community should advocate and preach one thing – flexibility coupled with open mindedness. In the end, these two are which preceded any invention, breakthrough mankind has made. And exclusively so too. We should realize that, any kind of philosophy, method, approach has their downsides and upsides, and things change, making what we knew as appropriate to become inappropriate for solving a problem or accomplishing a task.
But foremost, we should realize and always keep in mind – different perspectives enrich knowledge and its applications.
For, the greatest asset of a programmer is an open, flexible mind.