I am currently consulting for a very successful dot com. My gut feeling is they have me in there to stir trouble. As right now they are in discussions about refactoring their entire codebase to be more OO.

I am going a bit crazy as it their third attempt (before I came) to do this, so now they will have 4 frameworks!

And of course none of these advocates will be the ones to do the migration of legacy code

I will be making a suggestion to move all of their core .php into a java API (at the moment they already do everything in memcache, redis and java anyway), and keep the .php lean, clean procedural code like it was originally written.

Most of these discussions are not about the topic I’m interested in, but I still cannot resist adding my comments.

First take a step back, and see what it is all about: Algorithms. This is more important than it appears. Both paradigms are focused on specifying a way to solve a given problem an imperative manner. They are specifying the structure of their data and instructions on what to do with the data, both on a way that can be executed by a machine. This is in contrast with at least two other paradigms that all of you must know: querying languages (SQL), and markup languages (HTML). But in this classification PHP is an imperative language. It implements syntax and language constructs that are optimized for OOP. What is the real difference then?

In fact OOP is an epiphenomenon of Procedural. So there is no OOP without Procedural. It just takes a different approach of linking the data and instructions together. Inheritance and polymorphism are just two concepts to support that approach. Inheritance is to DEFINE the variations of data structure (a property) and the corresponding variations of instructions (a method) of a class. While polymorphism is to DECIDE which method is applicable to a given object (instance of a class).

Arguments about reusability in this thread were more about the quality of code. But there are different ways of writing both OO and non-OO code. It is possible to write a neat, easy to read code using the procedural syntax, and also a difficult to understand and messy code of OO syntax.

In principle what makes OO syntax more reusable, is the Inheritance and Polymorphism: Let’s assume you have an OO solution “A” to a given problem “A”. If you have a similar problem “B”, it is likely that Inheritance helps you to derive a solution by DEFINING the differences only. If you later enhance your solution “A”, it is likely that you can make use of that enhancement in the solution “B”, too. Now, let’s assume you have problem “A” and “B” with their corresponding solutions, and you have to solve a problem that involves both “A” and “B”. It is likely you can merge solution “A” and “B” without a collision (conflict of identifiers) thanks to Polymorphism. Yet, there are many more evolved concepts of OO, but these two are the most important.

In general a non-OO solution cannot warrant this. It is less likely that a non-OO solution can be reused without changes, so that future enhancements to it could be incorporated without modifying the derived solution. And on the other hand identifier collisions are more likely, and quite difficult to detect. Yes, these make reusability difficult in general, but not impossible. Especially not in case of a well designed code. If your non-OO code is designed carefully, these issues can be avoided, because PHP provides concepts to overcome them. In the next paragraph I list such concepts.

I’ve studied various imperative languages in both practice an theory. The past few years I spent on PHP, and I found that PHP is a quite exciting one. Most of it’s characteristics are closely linked to its implementation (rather interpreted than compiled). Many of you found that it is possible to create a solution by using a fundamentally non-OO design pattern tied to the OO syntax. It is true, and not only in PHP. This is because OO is an epiphenomenon of the Procedural paradigm. What I found more surprising with PHP is that it is also possible to create a solution using a fundamentally OO design pattern tied to the non-OO syntax. Here are the key concepts/features of PHP I found essential making it possible: the four variations of external code referencing (include, require with and w/o _once), associative arrays, passing variable number of non-typed parameters in procedure calls, using string variables instead of procedure names, rich ways of handling functions (call_user_func_array, call_user_func, create_function, func_get_arg, func_get_args, func_num_args, function_exists, get_defined_functions), exception handling, namespaces.

Without studying the actual implementation of PHP, I would be greatly surprised if most of these concepts were not implemented in order to implement the necessary features to support the OO paradigm. Further I presume that the same concepts/features are actually used during the execution of code using the OO syntax.

In a legacy application model the source code is compiled to executable, then the executable is loaded into memory (or just the source code is interpreted), storage structures is initialized finally the operational instructions are executed. The latter may mean whatever, an event loop, parsing an HTML source code, or virtually anything else. If the programming language supports OO AND the problem is suited to OOP, it worth using OOP to code the solution. Otherwise it either not possible OR does not worth using OOP. It is also a possible approach for an HTML to PDF converter written in PHP and called in the command line.

That’s what I know. But I’d be rather interested in the side effects of using the OO syntax in the typical context of PHP. What is that(?): a web application. That is a distributed application, where one side (the server side) is running in a stateless and connectionless manner. PHP provides a concept (Session) to overcome (I do not consider security matters here) this problem, but what actually happens is more complex than it first appears.

The execution of a web application consists of a series of HTTP requests. Most of these requests are executing a piece of PHP code. Each of this code pieces are executed in separate processes. This introduces a persistence issue. It means that the state of the web application must be stored somewhere between two consecutive HTTP requests. Web standards are especially rich in diverse solutions, but a single versatile way does not exist. In PHP the session (in conjunction with cookies, etc.) is a maintained execution state between consecutive script execution processes.

In a given process the PHP code can use a session to set its initial execution state identical to the final state of the previous execution. There are certain limitations, e.g. at any given point in time only one PHP script can access the data of a given session. So concurrent requests are not possible or at lest need special treatment. Here we came to a very important point that is linked to a key difference in the Procedural and OO paradigm. This is the matter of code execution flow during a process. Assuming a single threaded environment the flow of code execution is well defined and deterministic. But in case of a pure Procedural code it is also easier to predict contrary in case of an OO code, where the next instruction may also depend on the actual type of the object in focus. There are further attributes (such as more complex storage schemes) associated to OO design pattern that may bring further overhead to session handling.

These attributes are not limited to OO syntax. They also appear when using an OO design pattern tied to non-OO syntax, but there is a huge difference. In case of OO syntax the programmer lets PHP to deal with them, while in the procedural style PHP lets the programmer to do it. This is a very important difference. In a pure Procedural code (without any reference to classes) saving and restoring execution states has no prerequisites. Data can be serialized and unserialized easily. Of course there are certain data types (e.g. file handlers) that cannot be serialized, but the programmer can treat them properly in the code. But in case of the OO syntax the class definitions must be parsed before any piece of data can be unserialized. Please remember that the instructions are tied to data, so class definitions also include all the methods. Therefore if the code is written in pure OO syntax, this means the full source code of the entire application.

Now imagine a somewhat complex web shop then assume an AJAX call to update the total cart value based on the change of an item quantity. It sound simple, but the OO syntax brings an enormous overhead. I’m not against OOP. I’m working on various projects in various platforms. Some of them are prominent examples of problems desiring the OO approach (a model railroad controlling application), in a context that is well suited for and OO solution (Win32), while some of them are not. In my opinion PHP web sites in their entirety are not well suited to OO. But OO is very powerful in certain subparts of them, such as parsing an XML file and rendering a document.

Based on all the above, I MUST agree JG (September 22, 2011):
“OOP is for people who can’t properly engineer software or for competent programmers who are involved in very large or complex non-web project. If I were to write an event-driven game to run on a PC, I would not choose procedural programming.”

A presume his framework takes an OO approach but avoids using the OO syntax of PHP. It is likely not only because it is not necessary, but it would also bring unaffordable overhead.

And I disagree slightly Michael (November 22, 2011):
“And, anyone who claims they can build “just as powerful a framework” in procedural style code is either writing an incredibly bloated code base, or is simply lying.”

I disagree him, unless “bloated” means a smart design of code that adverts principles of an OO design, but avoids the inherent overhead of the OO syntax in highly interactive PHP web sites using a plenty of AJAX requests.

I’ll give a simple example before I leave, even though I don’t think it will change anything since most people above me simply don’t have the level.

10 years ago, pretty much all websites were big HTML tables to position their stuff. Then comes css… Now you still have idiots who tells you that you can do the same with tables etc…. But ye… No serious website doesn’t use css. Yes you have to learn how it works, but I think we can all agree that it is worth it. Same goes with OOP, only problem… you can learn css in a few hours, OOP takes years to master. A web application is relatively simple and small compared to other stuff, that’s the only reason why procedural is even possible.

Now do whatever you want, but believe me on one thing: If somebody tells you that procedural is better, he simply never reached the level to actually understand what’s he’s talking about.

Someone wrote:
“OOP is for people who can’t properly engineer software or for competent programmers who are involved in very large or complex non-web project.”

I am guessing the person who wrote that comment has never had to develop a large scalable reusable web platform.

Someone else wrote:
“It is very easy for OO programmers to pretend they are producing quality code, whereas in fact they are programming an infectious monster that does not offer any or many opportunities for elegant re-use outside of the initial problem domain. This is the case a large percentage of the time with most OO PHP programmers.”

I’m sorry that has been YOUR experience. However, saying something like it’s the “LARGE percentage of the time with MOST OO PHP programmers” would seem to indicate you are somewhat biased on this subject.

My observation is that programmers who started procedurally have great difficulty transitioning to OOP, simple because the thought process is very different. And the responses in this thread seem to support that notion, as the ones railing against OOP talk about 30 and 10 years of experience. In my current job, I am cleaning up a previous developers work, who had 30 years of experience, because he wrote a completely new “procedural” style system to do all the work that extending one class could have done. It took me less time to extend the class than it did to delete his work.

And, anyone who claims they can build “just as powerful a framework” in procedural style code is either writing an incredibly bloated code base, or is simply lying.

And using the worst examples of code i.e embedded HTML inside a class, is not an unbiased argument either, as I’ve seen far more embedded HTML in procedural functions than in any OO classes. So it goes both ways, there are horrible examples of both styles.

The reality is, if you want to be a good programmer, you need to learn OOP, and you need to learn it well, because, as someone else wrote – “that is the future.” In fact, there are even arguments that PHP should be compiled, which perhaps will eliminate some developers who really shouldn’t be programming in the first place.

Learn OOP, learn procedural. Use whichever approach is best for the job. Arguing that one is superior or one is inferior just indicates you really aren’t a good programmer.