ryochiji's blog

OO vs Procedural Programming in PHP

I came across an article on zend.com about object-oriented vs procedural programming in PHP that I found somewhat interesting. The article itself doesn't go into much depth, but I liked it because it took a fairly balanced view, and it's something that I've been thinking about for a while.

Show Rest of Post

posted in Devel at 12:56[1213 comments | View | Add Comment ] [PermaLink] [Trackback]

I tend to get the feeling that OO is supported largely by zealots, who simply believe that OOP is da shit. Most CS programs these days also seem to place a lot of emphasis on OOP, and at times, I've gotten the impression that non-OOP designs were simply considered bad designs. I've never really been a big fan of OOP, possibly because I started programming with a language that had procedures instead of even functions (i.e. Pascal). I mean, I understand and appreciate the merits of OOP, although I've always felt that it was rather over-hyped.

In PHP, though, things tend to be less one sided. PHP, at least with 4 (and to a degree, even in PHP 5), doesn't quite have all the object oriented capabilities that languages like Java or even C++ have, so there seems to have been somewhat of a division between the OO and procedural camps. The fact that each script essentially only has one entry point and one execution path per invocation probably also makes procedural approaches somewhat more intuitive (as opposed to multithreaded GUI apps, for example).

Personally, I think I take a more or less hybrid approach. IlohaBlog is pretty much object oriented, although I believe it started off being procedural and I switched to OO when I realized I needed an XML-RPC interface in addition to the web interface (separation of design and logic became a requirement). Every time I go back to change something, I appreciate its logical structure and clean design.

On the other hand, IlohaMail is mostly procedural for a number of reasons: I started working on it before I knew much about OOP, PHP4 wasn't out (or at least I didn't have it) and objects were notoriously slow in PHP3, and lastly, I simply haven't had the need to go completely OO. For example, the IMAP library could probably be converted to a class, although I don't see any actual merits in doing so. Really, the only difference would be purely syntactical.
Granted, there's a lot of cleaning up to do in IlohaMail, but that's more a matter of using better procedural programming practices, rather than an inherent flaw in the overall design (although, there might be some of that too).

One of the merits of OOP is that it encourages/forces you to organize your code in some logical fashion, and it also solves some namespace issues (which, I think, is a huge problem in PHP). However, both of these things can/should be solved procedurally as well.
Also, in my experience, large OO projects can quickly turn messy when you realize that your original design had flaws, or if there's a major spec change. I'm not saying procedural programming lets you deal with such contingencies elegantly, but simply that OO can turn quite messy, and at the end, you might just end up with convoluted code with extra object bloat to boot.

As a rule of thumb, I would recommend OOP for cases where reusability and legibility are important (i.e. generalized utilities that can be used in multiple apps). But everything else (which, unlike what OOP advocates claim, tends to be a lot of code) can probably be left as procedural code, provided that it's still relatively well organized, documented, and fairly well thought out.