I originally wanted to name this post “Object Oriented Concepts – Contd….”, but then the Hamletian dilemma came to mind. Every programmer faces this, even today, many years after OO has been widely accepted. Part of the problem is that the OO paradigm requires a change in how we think about a problem.
As we saw earlier, in traditional languages we always think “how to do a task” in a procedural sense. This we could adapt to – after all, we humans are good in giving instructions and making recipes and grocery lists. Programming was a natural extension of this – we told the computer what to do and how to do it. We told the computer what to do while feeding data (nouns) required as parameters to these commands (verbs).
When it comes to OO, we have to start thinking what will be the objects we need and “leave” it to those objects to do the work. Really, it’s just repackaging, but it’s not easy. We are now forced to think of everything in terms of objects. If it’s objects like animals, cars, people etc that are typically used in examples about OO, we can understand. But the moment we try to come up with objects for abstract concepts and purely action oriented tasks, it becomes a daunting task.
Baking a Cake
For e.g., let’s look at a simple problem of baking a cake (no disrespect to the chef in the kitchen, but let’s abstract it here as simple task here for a minute). A recipe typically talks about how to get, do, heat, bake etc. All verbs. Interspersed will be details about data to be used – how much flour, how much sugar, what temperature, how many minutes etc. These “nouns” are used as parameters to the recipe and off we go. Of course, every now and then people try to “reuse” recipes by switching ingredients.
This simple recipe for a cookie , that highlights these points. It has an instruction with 3 simple steps to make delicious cookies. It has some ingredients (attributes) mentioned – dough, apricot jam, and parameters like temperature at 350 degrees, time for 15 – 18 minutes and 1/3 cup of jam. It is straight forward and it even “reuses” recipe for “basic sugar cookie dough”! We certainly know who is making this cake – you, and the ingredients and implements you will be using.
In our abstraction in a procedural language, we created a program with the instructions to bake a cake. We probably broke down each step into a separate procedure (or function), and created a main function that looked like the recipe and called these functions to get the baking done. We created some variables outside of these functions for the parameters required. This works and even is simple to write. But, we assume a lot of things here, like the main function itself acts like the baker executing the instructions. Controlling the oven may be built in as a built in function, but at some point it has to call something to make it happen.
In OO, the task gets a bit more complicated! First, you would have to start thinking differently. Now, you will have to think about the nouns first. Of course there is cake, the final product. But, there is also the bowl, oven and a fictitious baker – may be you, but object none the less. These other objects were included in our procedural programs, but were not given much importance. Any reusable, replaceable parts of the program will now have to be separate objects. In our example, if we make the Oven and the Baker and bowl objects correctly, they could be reused in making/baking pies as well as switch to make or even pot roast! Guess what, you can even replace the baker easily!! This is what makes OO so reusable and to some “so bloated!”.
If you are interested in OO cakes, here is a link on a cake OO.
So, To OO or not to OO?
OO is almost everywhere around us. Language after procedural language (recently PHP, Coldfusion, ABAP, Flash ActionScript) have added OO capabilities in recent years. But then, there are also others that write about the difficulties and shortcomings of OO. The post titled Debate Still Rages Over Object-Oriented Programming discusses such dilemma. While you are there, don’t forget to check out Marc Funaro’s orginal post here: How OO Almost Destroyed My Business. He has articulated very nicely, why he couldn’t and didn’t have to switch over to OO completely. And see here for a funny take on Java’s OO techniques! Irrespective of such views, OO is here to stay. Even if you don’t use OO technology currently, chances are, sooner or later you may be exposed to it.
OO methodologies could get complex and could actually distract a developer from the original goal of getting a working program quickly. General rule of thumb I have, is to use procedural for any small (read quick and dirty – most of my utility programs and scripts fall under this) programs and use OO methodology for any larger (business, corporate, enterprise, framework) programs and programs that have potential to grow in the future. (The truth is, even the quick and dirty program/script could outgrow their originally intended lifetime and objects do creep into those every now and then!). OO definitely enforces certain planning ahead of time, so it takes a bit longer to develop it upfront, but if a program lives long enough, re-usability makes up for the cost over time.
In the cake example above, if I am just making a cake for the family on a weekend, simple procedural implementation would be fine! But, if you are going to be making a cake each weekend or thinking of starting a bakery with several branches down the road, then I better start thinking in OO terms, so we don’t have to re-invent a lot of stuff later.
General Design Considerations
- Keep your code Clean
- Keep it modular
- Make the code Reusable