Procedural vs Object Oriented PHP
0As someone who oversees the development of various browser based applications on a daily basis, I commonly come across the dilemma of using objected oriented or procedural programming with PHP myself. Since the advent of PHP 5, the use of classes and objects has become a privilege that was previously not available to PHP developers. Developers have always argued that no matter what, object oriented programming is the right and only way to go forward.
Yet, there is a plethora of PHP developers who refuse to change their ways and focus on developing under the procedural methodology. I have long been of the opinion the right methodology is driven by the nature, scope and goals of the project. Many will disagree, but saying that using object oriented methodologies for writing all or any scripts is like saying you want the best for nothing. Everything has a cost, and software development is not different.
Robert Peake is an internationally renowned developer who regularly writes for Dev Zine, and he has put together a long, comprehensive article on what the differences are between projects that require procedural programming and projects that can, perhaps, afford the luxury of object oriented programming. I happen to agree with him.
The concept of object oriented program is great. The application is even better. But like all philosophically powerful abstract concepts, object oriented programming will take longer, cost more money, and in many cases, will execute a lot slower than code written in a procedural fashion. That said, I believe, the following is a very brief, and by no means fully comprehensive, list of characteristics to consider when building applications with PHP 5 under either of the methodologies:
| Procedural PHP | Object Oriented PHP | |
| Budget | Tight | Not so tight |
| Timeline | Tight | Not so tight |
| Will need to develop APIs / Web Services for other parties to interact with application | Not necessarily | Yes |
| Application Speed is Critical | Yes, it is of utmost priority | Speed can be sacrificed for quality of code |
| Time available for good documentation | If it is well documented, procedural code is not that difficult to follow | Documentation helps, but independence of objects doesn’t make it as critical as in the case of procedural |
| Independence of data and structure | Somewhat critical | Vital |
| Adaptability of code | Medium | Highly adaptable |
There are several other factors to consider, but the above should give you a very basic idea of how this works. Most business applications are mission, time and budget driven. Therefore, the chances that the business will spend extra money quality code (which usually doesn’t mean much to a business user) and go with the object oriented methodology are slim to none. This is the reason why most software houses develop code using procedural methodologies with PHP.
Ultimately, it is up to the customer to make the choice between paying more and waiting more for a product that will do the same, but may become useful and less expensive later on. It’s not always the case of a wise investment, so many businesses don’t particularly care. Usually, though, it should be the decision of the project manager, keeping in mind the scope, nature and goals of the application in question.
However, what cannot be overlooked is there are some very powerful and widely used open source applications written using object oriented methodologies. Developers who embark upon such projects do so with the goal of creating good quality code. The reason why such applications become so popular and widely used, however, is that they are based on objects and are highly adaptable and easy to understand. Unfortunately, it’s not always possible to use this approach in business programming, because the end result is usually more important than the journey.
Personally, it is one of those dilemmas which breaks my heart. That said, choosing the right methodology can make or break your software or your business. You should, therefore, always pick your software and technology partner carefully.
This article is reproduced from one of our other websites which is no longer active. It was written a couple of years ago.
