OO: the lingua franca of modern software design

Posted at 08:00 on 26 March 2009

There is no excuse whatsoever these days for working professionally as a developer and not being thoroughly familiar with object oriented programming.

Occasionally I meet people who have some crazy idea that it isn't necessary, claiming that it leads to over-complicated code that is difficult to understand. Indeed, there are some software packages -- WordPress springs particularly to mind -- that make very little, if any, use of OO, yet they do pretty well. Furthermore, I wouldn't necessarily expect new junior developers to be completely up to speed with it -- after all, we all need to start off somewhere, and it's perfectly reasonable to cut them some slack right at the start of their programming careers.

However, if you are working professionally with code, whether as a web developer or as any other kind of developer, then regardless of whether or not you are actually using it, getting to understand OO properly needs to be right at the top of your list of priorities.

Why? Because OO is the lingua franca of modern software design.

OO has been mainstream for nearly twenty years now, and before that it had been knocking around in academic circles and research labs since the sixties. In fact, it's now pretty pervasive -- nearly every framework out there is built round OO principles, and you can't work as a developer for long without running into it.

More importantly, OO is a communication tool for discussing your application architecture and design decisions with your fellow developers. If you don't understand it properly, or if you misunderstand it, you will not be able to hold a meaningful discussion with your colleagues about the structure and high level architecture of your code. You will not be able to understand why computer programs are designed the way they are, or why frameworks work the way they do. You will not be able to design your code to be easily extensible, nor will you be able to build usable, stable service interfaces. And you will be the one writing convoluted spaghetti code that is almost impossible to maintain.

You need to understand it correctly, though. A lot of developers think that they understand OO, but in actual fact, have numerous weird, fuzzy conceptual misunderstandings as to what it's all about. Just wrapping a bunch of procedural code in a class doesn't make it object oriented any more than going into McDonald's turns you into a hamburger. Not knowing the difference between static methods and instance methods is a dead giveaway here -- if you are creating instances of a class consisting entirely of helper methods, you're doing it wrong. I've come across numerous examples over the years of this kind of thing:

public class Helper
{
    public int SumOfSquares(int a, int b)
    {
        return a * a + b * b;
    }
}
 
/* elsewhere */
 
var objHelper = new Helper();
return objHelper.SumOfSquares(a, b);

which could just as easily be written as:

public class Helper
{
    public static int SumOfSquares(int a, int b)
    {
        return a * a + b * b;
    }
}
 
/* elsewhere */
 
return Helper.SumOfSquares(a, b);

Now this is a relatively trivial example and one that is fairly easy to fix, though I have come across variations on this theme with the potential to introduce resource leaks or other obscure, hard to track down bugs. Much more serious, however -- and harder to fix -- are the maintenance nightmares, such as methods taking dozens of arguments, all of them primitive types such as int, char or string. Or very long methods containing a lot of complicated copy and paste code. Or huge, ten thousand line classes with more responsibilities than the Secretary General of the United Nations. These are the kind of problems that OO, design patterns and the SOLID principles are designed to solve, people.

Well designed OO code may be difficult for novice developers to understand, but it is not a problem to experienced OO practitioners. On the other hand, poorly written code, written by people with vague, woolly ideas about how code is supposed to be written, is a huge problem to novices and experts alike.