When to use object-oriented versus procedural programming
PHP was initially envisioned as a way to get dynamic content onto a webpage. And to that end, the creators assumed their users would write a website in HTML, and then intersperse PHP code at different points within those pages in order to let them adjust to different situations. And it should be noted, PHP still works great for that.
But when PHP 3 was released, some engineer decided to add very simple, very basic object support. And it wasn’t even object support the way most object-oriented languages would describe it. Yes it was a way of keeping a collection of functions and variables inside a separate scope. But under the hood, it was really just associative arrays powering it all.
But surprisingly, a lot of PHP developers started playing with objects, and they liked some of the things they could do with them. So, over the years, PHP has started to look more like a traditional object-oriented language. Now, pretty much any design strategy you can accomplish with a mainstream OO language like C++ or Java, you can implement in PHP.
A question I hear a lot from people starting out with PHP, is “Does this look like a project where I should pursue an object-oriented approach?”
The answer depends on a number of factors.
The first point I should get across is that there is a performance penalty when you use objects in PHP. There is some overhead PHP needs to add in order to create objects, and if you were to design 2 separate websites that did the exact same thing, down to the last instruction, but one did it all procedurally, and the other used objects, the procedural site would be measurably faster.
So, when deciding whether to use objects, the first question you have to ask is what will you gain that makes the performance penalty, albeit a small one, worth it?
Well, first off, objects let you abstract out portions of your code. That means that you can have objects that pretty much take care of themselves, and when your code interacts with them, it doesn’t need to know exactly what they’re doing in order to use them. This means that if you want to change how one part of your project works, it can be decoupled from other parts to such a degree that those other parts won’t also have to be modified. At least, not in most situations.
The second advantage objects can infer is the ability to avoid code duplication. Code duplication can happen when you have particular tasks that get done many different times throughout your code. Now, some of the problems with duplication can be effectively dealt with by using custom functions. And functions don’t have the same overhead as objects. So if your project is small enough that, with a manageable number of functions you can avoid code duplication, then that’s probably the best approach. But when that list of functions becomes very difficult to manage, then much like organizing your computer’s files into folders, organizing your functions into class methods can make your development much easier.
The last advantage is that, once you get the hang of objects, it’s actually much easier for most programmers to envision their data and logic as distinct objects. And if it’s easier to understand how your application or website is built, then it will be easier to bring other people onto your project. So, whenever your project is going to be large enough that multiple people will be working on it, objects are almost always going to be worth the overhead.
February 02 2010 08:52 am | Schmategories