Which one works best?
Are you a newbie in the PHP language? If you are, for sure you have encountered two kinds of PHP approaches programmers use nowadays: the procedural and the object oriented (OO). Different experienced programmers have already used both approaches, and most probably they would recommend only one kind of PHP approach to you. There are some who would say that it’s best to stick with the traditional procedural, while others would say that OO is much better to use. It can be quite confusing as to which approach to follow, but in order to make a choice, you must first know the pros and cons of using procedural and OO PHP.
For novice programmers, procedural PHP is probably the first PHP practice you will be exposed to. It’s because it’s the approach almost every programmer knows how to use, and its traditional tenets have already been established and easy to learn. Most web pages operate in a procedural manner, i.e. this tag, then this tag, then this tag, and so on. Using procedural PHP code with HTML is rather straightforward unlike OO, and programmers are given more space and freedom to create their own styles using the procedural approach.
Procedural PHP works heavily on the performance behind the code, thus programmers tend to come up with codes only they can understand. This is one of the major disadvantages of procedural PHP; in the effort to make things faster and more efficient, you create codes that cannot be used by anyone else, unless they get to figure what the codes are. Procedural PHP is also quite difficult to maintain, extend and distribute, unlike OO.
On the other hand, object oriented PHP or OO, are more inclined to work on the front lines of the programming world. In OO, you do not really have to think about the performance behind your creation, since you’re doing it for the sake of eye candy. Moreover, OO PHP is easier to distribute and maintain, since its main goal is to be placed anywhere and everywhere in the web. If you plan more on taking a career on web design and documentation, then OO PHP is for you.
OO also showcases productivity. Unlike the repetitive process of procedural PHP, you can actually skip this process due the creation of class files are more organized and reusable. Thus, you do save time and have more space to customize the codes you have created. OO PHP works best when you have to use complex functions in your project, when you plan to use the same code in future projects, as well as when you can’t run certain functions more than once on a page without logical errors.
You can find a lot of skins, and other fancy designs that operate behind OO PHP, mainly because the said approach focuses more on the look and feel of the object, rather than its performance. Packages such as Smarty and FPDF use object oriented PHP, so if you’re about to use these programs, then OO is the approach you should follow.
Meanwhile, for fast-working programmers who divulge more on the functionality and performance of the codes, then procedural programming is the one for them. You can actually find them using programs such as osCommerce and phpMyAdmin.
Choosing between procedural and object oriented PHP depends on your needs and tasks as a programmer. If your work inclines you to do more on performance, effectiveness and functionality of codes when it comes to programming, then procedural programming could cater to your needs. If you on the other hand would want to explore more on the abstract and creative side of programming, then you may as well work on object oriented programming.
This post is not very well founded.
As a PHP programmer since PHP3, I have ten years’ commercial experience with the language, as well as fluent perl and good exposure to four or five other languages. Back in PHP3, there was no OO, and so that’s what I started with.
Having since had experience with both models, plus both models in perl, and modern OO languages such as Ruby, I believe I am reasonably informed.
I believe that it is often said that OO code is somehow more ‘structured’ or ‘re-usable’ than procedural code, and that this is simply incorrect.
Good PHP procedural code is just as powerful as OO code.
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.
For this reason I always emphasise the use of procedural code for overall logic. Object oriented approaches are only used on specific problem domains that are both well defined and well suited to the OO model.
Thanks for both this article and also the response made to it by Walter.
Im new to PHP, just starting, and for the last few weeks ive been reading and trying some basic things out.
I have been very confused mainly because of trying to understand the procedural approach while at the same time trying to take in the OOP approach too and its simply doing me no good trying to learn it this way.
After reading what has been posted here im going to get my head into learning the procedural way, and i think it will relieve me of some of the confusion that ive recently experienced.
I was starting to get frustrated and someone on a forum was even trying to talk me into the OOP way, i thought learning OOP PHP was what i simply had to do, like its a must but i realise now that its not.
Procedural PHP here i come.
I agree with walter.
There are so many OO programmers that writes OO codes but they don’t understand the principle of OO Design Pattern. Some just write codes the OO way without any design pattern, so that the execution performance it self is so slow.
Quote : Object oriented approaches are only used on specific problem domains that are both well defined and well suited to the OO model. >> This is where design pattern apply i think.
CMIIW
I also agree with Walter.
OO programing requires you to code a function and then extend that function to do something else or add functionality to it and then again and again until you get to a point where your original OO Class is so large and bloated that it does not do anything well.
With a procedural approach you can write reusable functions that are fast and can be called from other functions so you don’t need an entire class to perform a simple task.
If you are just starting with PHP go with procedural methodology, but you will still need to know OO since a lot of good tools use OO such as Smarty so you will need to know how to use it.
-Alex
@Landon, thanks for the compare/contrast. I think in the future we will be moving more and more to object oriented programming (OOP), which I think is a good move. However, I am torn between this and procedural when it comes to bigger applications. I agree with @Alex on the fact on reusable functions. I am in favor of procedural especially for large web applications and more so for large applications that use lots of jquery.
agree with walter! i rather choose with the basic fundamentals.
I have good few years of experience, mostly with procedural. I have had to rip apart the code of both procedural and object oriented programmers, and the truth is, both styles can be really really horrible.
In most cases, when it is OOP and a severely tangled mess, I have abandoned any salvaging, where as procedural does seem to have a little more sense about it, or clarity when tracing through everything.
The only thing that matters is separating your logic from your data an keeping it as clean as possible.
Reduce, Reuse, Recycle.
Just My Opinions.
I don’t mean any disrespect but I need to get this out to you guys.
Don’t listen to these people; they have been programming for years and it’s harder for them to make the transition to Object-Oriented Programming (OOP). Like Walter said, before OOP wasn’t even available, but it is the way of the future. “It makes your code slower” ? Yea right, how slower? Will it even matter in a few years when technology will provide us with super fast servers? Forget about speed, that’s going to fix itself. Worry about maintenance, structure, and usability.
I’ll give you one example: 10 – 15 year old kids don’t give a sh*t about older games or systems like super nintendo or nintendo; they just care about the PS3 and the XBOX 360… all the newer stuff. And why should they care? It’s the way of the future. Same concept here with OOP. If you invest time in learning OOP, you’ll better off. Fortunately for me, I’m a new programmer, and I never really learned procedural styles anyway.
I know its not easy to suddenly start doing things differently when you’ve been doing something a certain way for a long time. But it’s not my fault technology moves fast, and the demands for improved programming become more and more changing.
Nevermind all this bs.. just do object-oriented…
Thanks Walter,
I have been learning PHP for the last few months, and I have started learning OO recently.
I have enjoyed learning procedural PHP, but for some reason I find OO more complicated.
I will strongly disagree with the assumption that procedural code is messy and cannot be reused by others. It all depends on the way you set up the code and the way you use the native features of PHP. By the way, I started programming before most of your readers were born.
I use a PHP framework that I wrote myself. There is no object oriented in it. Not one line. I reuse my code all the time. To start developing a typical web application, I change a few things in the main configuration file, I run my SQL to create the core tables and here I am with automatic session, user-management, authentication, grids, pagination, forms, validation and the rest of it. This after 15 minutes.
Is my code messy? No chance. The functions are stored in modules and only included if they are needed. Just like classes. My functions are all named according to rigorous conventions and no classes are possible. All the grid functions are named grid_create() grid_pagination() etc… An intermediate programmer would be able to read my code and maintain it without difficulties. I have 20 years of Object Oriented behind me and I know exactly why I returned to procedural programming.
First, most of the classes available on the web are total rubbish. Go to phpclasses.org (a great site run by a very competent guy) and see the number of classes that are only reusable in the context in which they were designed. Many classes embed html to produce the results. That is totally counter-productive. You have classes that hard-code the connection to a database for example. Did I mention how fat some of those classes are? For most web applications, classes are a waste of time. You simply do not need the benefits or the negatives of OOP. And a lot of classes are merely wrappers for procedural code.
I laugh at the suggestion that only OOP saves you time and give you re-usability. In all cases, you need to start your script including the class file and creating a new instance. I don’t even have to do that. I just include the module and if autoload is set, it does the job. I never have to deal with paths. My system module handles all paths from some basic original configuration. There is not a single function call outside the system module that deals with paths and that is valid for the include() which I never have to use because I have a custom version. And the list goes on. By the time most OOP have typed the include statements and created new instances I am already done. I have built-in CRUD, forms, validation and the rest of it.
My modules communicate with each other through a clever system and for example, my grid generator (and other modules) connects to a data source area that can retrieve data from DB queries, CSV files, PHP native arrays, config files, flat files and so on. How many classes do you know that have this kind of flexibility when dealing with source data?
Did I mention how easily I can debug my code? When my script does a sys_exit() and debug is set to true in the config file, it dumps all the information I need. Oh, and finally, my code is much faster and leaner than OO code doing the same thing.
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.
The notion that procedural programming is difficult to understand is completely untrue. What is difficult to understand in the following code? :
sys_include_module(“form”);
if(form_is_posted(“myform”))
{
if(form_validate(“myform”))
{
// do some processing here
}
}
form_write(“myform”);
html_register_object(“myform”);
sys_send_view(“myview”);
sys_exit();
And just in case you wanted to know how many global variables I use, my entire framework has one global variable.
What makes strong procedural scripts is the structure and the conventions that you follow. I took the best bits from OOP and MVC models and put it together without the hassles and the restrictions. Consider PHP frameworks like CodeIgniter. They need to include “helper” functions. Why? Because pure OOP can’t do the job at the cost of reasonable overheads. Another good framework is Yii. But the programming style is too convoluted, too restrictive and time-wasting. The rule of thumb is this: if it takes you more time to work out how to use an OO framework than re-using your own procedural code, go procedural. Yii is a very good example. It is a great framework but most people would not be able to use it productively.
I agree that procedural coding from scratch would waste a lot of time and possibly be messy. But so would OOP if you were to write all classes every time you develop an application. Let’s not compare apples with oranges.
Hi JG,
Thanks! I love your comment. I completely agree, I think procedural in the right hands can be powerful. Look at WordPress which is all procedural and not OOP or MVC.
I think to make procedural really effective you need to apply some of the OOP/MVC methodologies like modular code which it seems you done that with your framework.
I think it really comes down to the developer. There isn’t a specific tool in the shed that makes someone better then someone else alone, most of it comes down to the individual and how effectively they use the tools that are available.
Happy coding
JG, I agree with you 100%
What is fascinating is the blowoff guys like Juan above spew out. “I have no experience but OO is the way to go because it’s all I know”….. I’m like you, I have 18 years experience and use C, C++, java, ruby and PHP. I absolutely love PHP procedural for exactly the reasons you state. I’ve run teams of 50 where I was forced to use OO, but I prototyped everything in procedural in mere days. The OO replacement took months to roll out. This was a terrible terrible reminder of why the OO agreement is so fictitious. Bigger teams meant slower delivery, not better software.
I have now decided to focus only on procedural PHP for pure enjoyment.
I also strongly agree with you. I’ve smaller experience then you (“only” 10 years), but I’ve also tried to take the best from each programming style, and I found I work way better in procedural. Anyway in some cases (a few) OOP is just a little bit comfortable, and I don’t mind to mix the styles if I need.
The better example is the framework I created for my job. I developed a multi-funcional web application, because once in a while my boss come in my room and say “oh well, you have to create a backend to that website” or “Darsch can you please create an application to do this this and this?”. So some structural code is OOP, meaning that I’ve an object to store/manage user authentication, another related to the forms/html code, another for menus/session variable/user data/etc, and so on, just because I like the comfort of a single object containing all the things related to a certain domain. All the rest (core functionality files, libraries, etc…) are all written in procedural style. And proudly, I’d say.
People always told me that I work with procedural programming because I’ve always worked alone, and not in a team. Well, I don’t know if I would change my style if I worked in a team. Maybe I’d take a lot more care in separating logic from presentation (which actually I don’t care a lot, since I’m the only one that puts hands inside my code… and maybe this is a way to descourage other in putting their hands into…
), but I don’t think that procedural style is automatically non-maintainable.
Anyway, you have some really interesting comment in this post. Thanks.
Ooops, I forgot to click “reply”. The previous was meant to be a reply to JG comment, which I strongly agree with.
I’ve been programming 30 years and had a few goes at OOP but always go with procedural in the end for websites. It does what I want and is ENJOYABLE to program in. I think that is the main thing… if I didn’t enjoy it I wouldn’t be doing it and perhaps I’m just too old to change but OOP does my head in!
I think it more so comes down to the programmer/developer. If the person doing the work is talented, they can get the job down right using either!
While this article seems to have elicited some polarizing views, the truth is that there is a place for both OO and procedural PHP. And a “good” programmer would know when to use one instead of the other.
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.
You guys… Whoever doesn’t see the advantages of OOP is simply not coding OOP. A friend of mine uses classes etc. in PHP and thinks he’s coding OOP, while he isn’t at all. He simply uses its syntax, while the logic behind is still procedural. No matter what I’m telling him, he doesn’t want to understand. Basically if you believe that procedural is as good as OOP, I’m pretty sure you’ll never reach the point where you’ll understand real OOP and see the advantages of it. Sorry guys.
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.
That is a great point. It seems like your friend is doing thing similar to WordPress actually. It uses classes but is still procedural.
It was interesting to read this discussion. I came to this site because I was interested in the advantages and disadvantages of OO codes in the typical context of PHP. I think the typical context: web based applications, really matters here. But most of the arguments (luckily not all of them) were discussing OOP vs. Procedural in a general context, which is not the right approach here.
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.
a) Too many big words
b) You need a tl;dr;
c) What you wrote is my thoughts too
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.
I still stand by my previous comment above, however, I’ve been learning OOP, and I have to say that I am having more fun coding projects than I have before. But I still use procedural according to the situation.
I’m quite new to PHP, but I’m just developing CRM on productional server build on simple table oriented procedural framework in PHP. It’s very well written, so it’s very nice programming experience. I must admit, that I enjoy this programming more than OO Python, which I use in other projects.
I’ve used several OO PHP Classes from other developers in this CRM project for some specific tasks (email, pdf, xml) and in some cases, I’ve found the OO approach significantly slower than procedural approach. Especially in the XML exports. I was able to “upgrade” the OO Class with some IMHO strictly procedural approaches (like transformation of recursion into iteration), which made 500+ records export from 45s to 0.1s
So I would tell, that in cases of representing complex structures is the OO much more flexible, but in serialization of tasks on thousands+ records gives the procedural programming more freedom in speed optimization, which can be sometimes really significant, even in interpretive language.
BTW: I’m running this CRM on VPS with 1 core and 2GB of RAM, so optimization is my best friend
Just my 2 cents.