Object-Oriented Blog Process - III

It's 9:30am on a Saturday, and I'm up fully dressed, fully bathroomed (in lack of a better word) and writing a blog entry. For all of you who knows me through my blog, through #coldfusion on dalnet, through email or other cyberspace means of interactions this might not seem so significant. But if any of my work coalegues had seen me they would have been pretty close to calling 911 (actually the number here in Norway is 113). The reason for this is that I am an extreme nightowl, and at this time in the mornings on normal workdays I'm hardly awake despite of the alarm clock screaming in my ears, my wife pulling my hands and legs (that is if she is awake) and my two year old daughter jumping up and down on my head (my five year old is sleeping long, just like me). On a Saturday morning the alarm clock is shut of, my wife and five year daughter are asleep and my two year old is downstairs with the grandparents. So I would normally be passed out for a couple of hours more at the least.

Ok - what on earth does this have to do with OO you are probably asking yourself (if you are patient enough to still be reading). Well the reason I am awake and writing is this: I read the first half of the first chapter of "The Object-Oriented Thought Process" yesterday evening. And while I had no problems what so ever falling asleep when I went to bed (around 2am), my head was started working hard in the morning (I probably was slightly awaken by the two year getting out of her bed and running to grandparents).

In short, here's what got me thinking:

In Object-Oriented programing you have the data (properties) and functions (methods) all nicely gathered within the object, while in procedural programing the data and the functions working with the data are separated.

Now, I knew this from before, but somehow, based on yesterdays reading, my understanding sored to a whole new level this morning still half asleep in bed.

Consider the following situation:

You are running a webshop selling,....let's say... golf equipment (this one is for you Scott). And in this webshop one of the zillion items is a "Boyzoid Custom High-Speed Golf Ball". Now this golf ball is presented on it's own product detail page, in the golf ball category page, on the recomended product page, and on several other pages as well. On each of these pages you are using queries to the product db to get information like product name and price. So far so good.

But then you realise that the golfball need to belong to a tax group (in Norway it would be 25% VAT on a golf ball). You could of course just put the price included VAT directly on the ball. But then you realize that if the VAT would change to 26% when a new goverment is elected you have to update the price of a zillion products manually (you can not run a script adding the 1% because some products belong to other tax groups that might not get increased). So you deceide to stick a taxGroupID property on the products, and then keep the percentages of the diferent taxgroups separate in tax group table in the db. Now on all the pages our golf ball is presented we need to add a query to get the apropriate tax percentage so that we can calculate the price. It's getting a bit tedious.

Then your boss comes up with the idea that you should have different super-sale categories, so you need to ad a property on the golf ball (and all other products) what super-sale category they bellong to, and then a separate table for keeping the percentages of discount for each category. So now you need to add yet another query on the pages for our golf ball getting the propper discount (if any) for the super-sale category the ball belongs to. Are you sure you remembered to add it in all places? Now it's starting to get nightmare'ish.

And so it goes on and on. Welcome to spaghetti code maintenance hell.

The OO solution:

You make your golf ball a product type object (an instance of a product class - more about classes and instances later) with both the properties and the methods. So on all the pages you just call the getPrice() method on your golf ball object. Whenever there's a change you just edit the calculation within the getPrice() method. You don't have to worry about going into the different pages the golf ball is presented at all.

Welcome to OO code maintenance heaven.

Some final words:

The example above is just that; an example. There are many ways you could make life easier a procedural code with custom tags, and other code reuse methods. On the other side, the example above is also fairly simple. There could be several other factors that could come into play, like diferent prices for different groups of customers, different taxgroups depending on the country it is ordered from etc. And still a webshop deals with relatively few and simple kind of objects and calculations.

If there are someone who now don't see the advantage of OO programing please raise your hand (in other words leave a comment). Actually that goes for all of you - I love getting feedback of almost any kind.