Why Use OO design?

There are several paradigms for organizing and writing code for a web application. I hate to use the word "paradigm", though, since it's a two-bit word, and some common paradigms I've seen aren't worth twenty-five cents.

Hopefully, if you're reading this article, you've already read the others, especially the one on The Basics. In that article, I give a list of important things to keep in mind when developing a web application. I give some superficial advice on how to adjust your design to meet these goals, but now I'm going to give you the best solution that exists at this moment, and it will probably remain so for a long time--the object-oriented (OO) paradigm.

For many of you, especially those who have no formal training in software development, the subject of object-oriented programming (OOP) may automatically turn you off. I can promise that it's not as difficult as the old Java dinosaurs would like you to think (they're looking for job security, you know), and any effort you put into learning OO principles will be repaid ten-fold when you write your next app. Let's see why.

Parallel to my Basics article, I'll cover each point and explain how OO design applies.

OO design makes it easier to code additional functionality in the future.

Everything in a well-designed OO application will be modular and separated from code that does a different task. It also makes following the "black box" principle a breeze. Once you code something that works and has a well defined interface--like public functions (methods) and what those functions get and give back in return--you don't have to look at the internals again. In fact, the rest of your code that may use this "black box" doesn't care what the internals are, either.

This also has the implication that you could code support for a certain feature into your application before you even code the feature itself. This is a great way to force yourself to stick to the "black box" principle and sketch out well-defined interfaces before starting to code a module.

- OO design follows the DRY principle by default. The easiest and most obvious way to follow the DRY principle is to factor your code into functions. OOP forces you to do this, to an extent. At any rate, learning OO principles will also help you think in this direction, even if you're not forced by the paradigm to factor your code.

- OO design requires that you correctly identify relationships in your data. Yes, it's true--sometimes OO programmers get it wrong. It's easy to do. But if you're thinking about everything in terms of objects, sometimes real-world ones, then you'll have a better perspective for accurately seeing these relationships.

OO design makes it easier to maintain your code.

As I mentioned above, using OO design turns your application into a bunch of "black boxes". If you change something in a module, as long as you leave the interface the same, no other code will be affected by your changes. This is a huge time saver. You don't have to lay awake in bed wondering if you've broken some completely unrelated part of your application.

- OO design helps you separate data from code. If your models are the only objects that are tightly related to your data, then most of your code will satisfy this requirement automatically.

- OO design helps you keep things organized. I've gotten confused trying to figure out a 10-page site coded using the "page-by-page" method (which is dreadfully popular). If an OO app is well-designed, even if it has a hundred features, you will be able to navigate the code and find what you're looking for quickly.

OO code is often usable in other projects.

This is an area where OO design really shines. How complicated is the idea of a category? Really, you could code something like this once, and use this code in every project that uses categories. Modular code is reusable, and everything in an OO application is modular.

To conclude...

I hope that I've convinced you that OOP is worth a careful look. Even if you never use it, after learning it, you will be a better programmer. Of course, I can't teach OOP in a single article. There are many, many helpful resources out there for learning about OO design, and I won't dare to try to trump them on my blog. Google is your personal research assistant, and he's just itching for something to do.