pros vs cons of procedural vs Object oriented of php

J N used Ask the Experts™

im curious if there are pros and cons of both. it seems like procedural style is fading away and more and more leading to OO.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
OOP is more of a modular approach and allows you to build a reusable code base that can be shared between applications. I wouldn't say that procedural is fading. It is still very useful depending upon what type of program you are building.

Here is a good description that I found on another forum:

I would choose OOP if:
 1.) There was a lot of code that could be shared and reused between the forms.
 2.) The data entry forms were anticipated to change often over time.
 3.) Many new data entry forms were anticipated to be added to the project over time.

I would choose PP if:
 1.) The forms were very unique and few elements were shared.
 2.) The forms were static and not expected to change much over time.
 3.) None or only a few forms were expected to be added to the project over time.

The main problem with OOP is that it requires a lot of artificial constructs in the code that is widely used, to allow broad general use.

jmiller's description is excellent, and if you don't know that you *need* OOP for your application, avoid it like the plague.  It is harder to manage, harder to change, and any changes have to be tested against ALL using programs.
Most Valuable Expert 2018
Distinguished Expert 2018
Have to disagree there yoderm.

OOP allows a much more structured way of coding - it's not harder to manage, or harder to change. As for testing against all programs that use it, that's only if you've designed your coding badly from the start!

OOP allows you to write a set of code for a specific task, and encapsulate it all in it's own container. That container can then be used across lots of different applications. It can be extended (inheritance) and overridden (polymorphed) if needed, giving you far greater flexibility than Procedural. It also follows the DRY philosophy of coding (Don't Repeat Yourself)

Don't get me wrong, procedural has it's place, and if you're writing very small, simple apps, then proceduraly will probably be the way you go, but as you expend and add complexity, you'll realy see the benefits of OOP.

If you're serious about coding in PHP, then you will have to get your head around OOP. Database Management is heading towards OOP (PDO mySQLi) and away from Procedural (mySQL). PHP5 is fully OOP capable and include a lot of classes that will make your life easier.

It's not really a definitive pro vs con argument, because it depends on your needs. Sometimes you just need a simply procedural function, other times you'll really bebnefit from the power of OOP - learn both :)
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

Most Valuable Expert 2011
Top Expert 2016
Rather than say one is better than the other, I would just say that object-oriented programming solves a different set of problems.  At its most basic level, in PHP, object-oriented notation saves typing and reduces the risk of typographical errors when compared to using arrays for compound data structures.  You do not need to put quotes around object property names and that means you do not need to to wrap variable declarations in curly braces.  This notational difference alone saves me a few typographical errors and test cycles every day.

If you're asking yourself, "What can I do with an object that I can't do with procedural programming?" you're probably asking the wrong question.  The better question might be, "How can I make my programming more modular and reusable, so that other programmers can reuse my work and can contribute to my projects?"  

Consider this article's example:

In the article we show how to create an object that you can use to compute an average location from a collection of data points.  Can you write this in procedural code?  Sure (inside the object you will find computations done in procedural code) but you can't extract the procedural code and reuse it in any other project without paying attention to the variable names!  That means a separate debugging cycle for every programmer who tries to use the procedural version and it negates any efficiencies that might come from code reuse.  So this brings us to one of the first and most important parts of object-oriented programming: Encapsulation and visibility of the properties (variables) and methods (functions).  You can take my class, put it into your library (you can even set up auto-loaders) and use it like a black box vending machine.  Put in what you want and get out what it gives you without any thought to how the innards of the object are working.  Never a care about the variable names.  Easy!

Now let's say that the class does almost exactly what you want, but you want to avoid the Haversine formula and use a more efficient plane geometry calculation for distances.  This is another obvious advantage of OOP: Extensibility and reuse.  You can extend the GeoObject class and provide your own definition for the compute_distance() method.  Nothing to rewrite and all other existing functionality remains intact.  Your only unit test will be the new compute_distance() method.  Easy!

Let's say that you're writing an application that does heat-maps from political opinion polls, and someone else is writing an application that tracks sensors in children's shoes.  The same class can serve both applications.  The heat-map class can be used to draw the maps, and the sensor application can be used to raise an alert if a child wanders out of a playground.  Of course you could develop these applications in separate and procedural code, but the debugging cycle would far exceed the time saved by reusing a common element of the code.  If you're a lone-wolf programmer nobody much cares, but if you're part of an organization that seeks efficiency from its software development staff, code reuse is very important.  Imagine bidding on software development projects when you had to start over from a clean slate on every project.  You would never win a bid because your competitors would have already built and debugged libraries of components.  They could do the same work in a fraction of the time.

I could go on and on (there are books written about this stuff) but hopefully you get the idea that OOP is all about solving the problems programmers have had for decades when working together on complex applications.  If you came to Object Oriented Programming and/or Object Oriented Design after you learned Procedural programming, the terminology and frame of reference may be confusing at first, but don't let that deter you from exploring the concepts.  The more you use it, the more you will find that it's a much better way of thinking about some kinds of problems.

Consider one of my favorite data structures, an array of objects.  With an associative array, you're pretty much restricted to a key and a value.  Of course the value itself can be an array, but what would you do if you wanted every data element to have some kind of initial processing as it was added to the array?  With procedural programming you would have to put the processing in line into the code that gathers the data and loads the array.  With OOP, you can isolate and debug the class definition of the objects, putting the processing into the class constructor.  Then as you add data to the array, your process of adding objects will automatically run the class constructors for each element of the array.  Your objects would naturally assume the form you wanted, just by the act of creating them with the new keyword.

Ref here:
I don't think it is a pro / con argument either. They are simply different tools that can be used depending upon your needs. The right tool for the job makes your life so much easier! Most of what I write is in OOP using .Net, but I have written some basic structural in other languages as well.
Most Valuable Expert 2011
Top Expert 2016


Electrician: "Apprentice, bring me a wrench."
Apprentice: "What kind?  Stillson, adjustable, pipe, lock, monkey..."
Electrician: "Doesn't matter.   I'm just going to use it as a hammer."
Top Expert 2014
You might distill this argument into the simple phrase "code packaging".  Once you get out of your line-by-line coding mentality, you refactor your code into units that you can invoke (subs and functions).  You can package these invocable routines into methods of one or more classes.
Most Valuable Expert 2011
Top Expert 2016
Good comment by aikimark!  You may also note that you cannot redefine native procedural PHP functions because a fatal error will be raised.  But in OOP, the parent classes can create functions that may be redefined by the child classes, making the language inherently richer and more nuanced.
J NUnicorn wrangler


thanks guys

It definitely looks like procedural will become a thing of a past as like ray said OOP makes the language more richer
Top Expert 2015

PHP is a top down / left right scripting language, and tries its best to be OOP. Shame it truly can't be the way the web is architected currently. Java / Javascript / Ruby / Python ... and so on. Those are OO. When PHP makes the jump into C extensions like it has been, e.g., HHVM, PHPNG, and other JIT or C style compilations, then it could be OO, but not as an interpreted scripting language that it is which forgets it existed every time it's invoking a script and is mainly (I've written apps that are persistent and it can't do it correctly or keep up with Java) used without persistent connections...

The reason you should learn procedural when OO style is available? When I learned programming, it was using the CL on IBM AS/400 - they invented SQL before Oracle - and that was a procedural language which loved to use GOTO. Similar to vbscript or batch files in Windows. It's 2015, and you shouldn't think that a language developed in the early 1960's has a place in anything you're learning today for the same reason you don't put faux wood paneling on a wall instead of drywall. They accomplish the same thing, but it looks ugly and people will look at you funny while valuing your input less.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial