Design Patterns and Encapsulation for Procedural Programming?

Question

I'm working on a fairly large PHP project written in a procedural style (it was written before PHP 5), and I can't help but feel that some of the things I'm doing are a little "hackish." A modification somewhere else can easily break the application. All the design patterns and best practices I've seen seem to only apply to OOP. I could start writing some of my code using PHP 5's OOP features, but I'm not sure if all the other developers are familiar enough with OOP.

Is it just the nature of procedural programming to seem "hackish" to people more familiar with OOP? Are there "best practices" books that deal with how to keep large procedural applications maintainable and make the introduction of new bugs less likely?

I know I could apply OOP design principles/patterns in a procedural way, but if I was going to do that, I might as well just use PHP's OOP features. Maybe I just don't have a good enough understanding of the procedural paradigm?

Answer 1

Procedural programming, especially in PHP, doesn't have a concrete notion of "encapsulation" -- everything's available, it's just not your job to modify it, so you don't. To those who don't know anything but OOP, or were taught that procedural code is BAAAAAAD, yes, it can look hackish and wrong. But people have been doing it for a LONG time, and it does work.

Now, it's just as likely that you've found some of the ACTUALLY bad procedural code. There's as much of it as there is bad OOP code.

Basic practices for procedural code aren't a whole lot different than for OOP -- avoid globals if possible, group related functions together and try to keep them short. There aren't really "patterns", per se, as procedural programming predates the patterns movement by a few decades. But clean procedural code need not be as ugly as the OOP zealots would have you believe.

Answer 2

My procedural code looks quite OOish actually. Quite often I have functions that pass around a compound structure, e.g. $page. And that would make it quite simple to transition any set_title($page, $title) into $page->set_title($title) if needed. It's just a different notation, there is no practical difference in what the methods accomplish.

Design patterns is a wide field. There are certainly things that will look silly if applied to procedural code. And frankly, some OOP design patterns are not very sensible in class based code too. But if there is a clear use case for rewriting your inherited code base, give it a try. I doubt your fellow coprogrammers are allergic to object-structured interfaces.

It sounds as if the problems in your application stem from the aged and convoluted structure. If it was written in PHP3 style, e.g. still uses $HTTP_GET_VARS, then don't try. If it's however just global variables and inderdependent code state, then bringing in some object-structure is doable.

PS: Global variables: Singletons in OOP are just overly elaborate global variables. Most applications need an array of config settings (just read, never written to). These belong in a global object or array. Everything else is dangerous.