Friday, 16 January 2009

OOD - The Second Coming?

Over the last couple of months I've been burning up my free time on a pet project (hence the scarcity of posting here). This particular project is a web application, and since I've always been a desktop or middle-tier dude in my day job, it's a bit of a step out of my normal environment to grapple with browser compatibility and suchlike.

Still, I wanted it to be a decent learning experience, so after a brief dalliance with Rails I scrapped the idea of using any framework sorcery and decided to write everything in plain ol' PHP, and lean heavily on YUI and jQuery to sort out the browser stuff.

This probably isn't an approach I'd use in future projects, but I bet I'll appreciate those frameworks a lot more once I've encountered and understood the problems they attempt to solve.

So, having strayed from the comfort of Rails and its clones, I had to think about lots of things like security, validation, data access, and how to organise my code. Just because I'd abandoned the training wheels I had no intention of falling over all the time - I still wanted a nice, maintainable app with sensible  abstractions, properly decoupled, and resilient to failure. Time to start reading articles and the odd open source project, obviously.

It's at this point I noticed something interesting. Since I regularly read plenty of development websites it could scarcely have escaped my notice that the trendy framework players (e.g. Rails, Django, Cake, ASP.NET MVC) strongly advocate the MVC pattern and class-based object-oriented design. What I hadn't really realised until now is how endemic that viewpoint had become.

In fact, beyond a few admirably out-there frameworks like Seaside, it's almost universal. OOD = good, EVERYTHING ELSE = bad. MVC = good, EVERYTHING ELSE = bad. No shades of grey, no room for dissenting opinion.

Go anywhere where best-practices are discussed and mention you're writing some procedural code, and watch the fireworks. It doesn't matter if your application has fewer lines of code than a newly-created Rails app has source files - if you haven't structured it with models, views, and controllers you may as well have written it in Visual Basic for all the bile you're going to have thrown at you.

If you say you're writing functional code, you might get away with it, since functional programming is still widely misunderstood and you'll likely be classified as some weird LISPer or Schemer doing something arcane and thus ignored.

Ironically, of course, if you grab a random Rails/Django/Cake app from github or Google Code, there's a pretty fair chance that what you'll find isn't particularly object-oriented anyway. Hint - usage of the 'class' keyword does not an object-oriented design make. And sweet zombie Jesus, I've never seen such abuse of the singleton pattern. That's a sure sign someone doesn't 'get' OO - the singleton pattern is evil and basically a way to shoehorn globals into an application without admitting it to your friends.

So, we have massive fanatical advocacy of a technique that will allegedly solve all your problems, coupled with large-scale real-world misunderstandings and misapplication. Does this remind anyone of anything? Say, for example, the last time OOD swept the world, panacea to all programming woes, about 20 or so years ago?

Don't get me wrong, I'm not arguing that class-based OO itself is just a fad - it deserves its place as a paradigm alongside procedural, functional, parallel, and numerous others. It's the heralding of OO as the one true way that seems faddish.

So, in the very best "bah, humbug" traditions I've written my app in unashamedly procedural PHP code. I don't mix my presentation and content. My data layer is decoupled and unit tested. Every bit of SQL is a parameterised query, to guard against injection. I don't have a single echo() statement containing any html tags. All my errors are exception based, and I don't have a single die() call anywhere. My average function size is about 10 lines, and my longest is about 20. I've no doubt that there's a legion of 15-year-old self-appointed geniuses ready to accuse me of inflicting yet more spaghetti code junk on the world just because "find . -iname '*php' | xargs grep class" comes up empty, but hey I'm OK with that.

I'm writing my next app in brainf*ck using ed.

5 comments:

  1. I've recently tossed up a quick community site. And while it's not a "web app" in the truest sense, I am working on adding some unique functionality.

    I chose to use the Drupal CMS, and there ain't a shred of OO PHP in it at all, and I think it's a very well build and thought out framework.

    ReplyDelete
  2. Considering that both Java and C# force you to use "OOD", can it be any surprise that many of the current frameworks trend that way? We're working on creating an entire generation of programmers who have only worked in languages that force you to wrap everything in a class, no matter how inappropriate that approach is to the problem at hand....

    ReplyDelete
  3. Hi Sol,

    I'd agree with you if all these frameworks were written in java or C#. My degree required passes in courses using C++, 68000 assembly, Haskell (and, yes, java), and I think it's a shame that so many degrees these days are so narrow.

    However, some of the worst culprits of the framework/OO lovefest are those using python and ruby, both of which have reasonable functional constructs and don't require you to use classes (well, not explicitly anyway). Yet still the tunnel-vision remains.

    It's particularly baffling given that Seaside's continuation-passing style is a genuine improvement in handling complex multi-page interactions over mucking around shuttling stuff to and from the model in typical MVC. Yet, as someone on reddit pointed out recently, Seaside will probably be obsoleted soon by increasingly powerful client-side javascript tools that solve the same problems less elegantly but more fashionably. Shame.

    ReplyDelete
  4. It's ok to have a comment.

    ReplyDelete
  5. Hi Russ,

    Great post. I guess in the end it all comes down to "Use the best tool for the job". And don't be afraid to mix things if it makes sense. It's also true that OOP has it's merits and there are cases where OOP makes expressing your code easier. Usually this is more visible on more complex cases than on simple ones.

    And finally about ASP.NET MVC ... i love it, even if a big part of it is using extension methods witch are just syntax sugar for free functions. They make perfect sense in the context.

    Again, great post and great blog.

    ReplyDelete