Introducing Object Oriented Design

Before the days of OO design, our applications would have data and functions, but there was not necessarily a tight coupling between related data and code (say a shopping cart and the code to add to cart and update cart totals). In practice this meant that any function could operate on any piece of data (almost – there was some information hiding using locally scoped variables within custom tags). Because of this, you never knew what would break if you deleted or renamed a variable as it could have been used anywhere within your application. Every small change to the application could break any other part of the application.

Of course, good programmers came up with a range of techniques and conventions they would follow, but it was possible to write truly horrible code and there were no enforcement mechanisms for best practices, making team development extremely difficult (hence the popularity of Fusebox which helped to solve these problems using a set of well thought out conventions).

With OO design, a program is broken down into objects which combine methods (functions) with related data (properties). In OO programming, the goal is to have as limited and terse an interface as possible (the pragmatics call it being shy) and to program to the interface, not the implementation.

The difference between an interface and an implementation is really simple. An interface is how people ask you to do something. An implementation is how you go about doing it. Because the way our programs do things changes more often than the things they have to do, programming to an interface rather than an implementation allows us to write more maintainable code.

The biggest difficulty in moving from procedural to object oriented thinking is moving from “asking” to “telling”. In Procedural Object Oriented code (I’m going to borrow the POO acronym here), you still ask the object for its information, which you then operate on elsewhere. In truly Object Oriented designs, you simply tell the object to do something for you. Of course, sometimes you need to ask an object for its data, but a good general heuristic is that if you’re asking an object for two or more pieces of information, you should consider getting the object to do for you whatever you’re doing with its data.

What does this mean? Well, instead of asking your TaxCalculator for the tax rate and whether or not to tax shipping and doing the math yourself, you just tell it to calculate your tax amount and it will return the value. There is still a dependency between your order and your TaxCalculator, but at least it is explicit and as long as you keep the interface the same (the information you need to pass to the calculator and the information it gives you back), it doesn’t matter whether you tweak your code or replace a lookup table with a third party web service - it won’t break the rest of your application.