I regularly find myself facing peers (ever since my college days) who are decidedly misguided if not moronic about the practical application of object oriented programming. For those of you lay folks out there who don’t know what that means, it basically means: programming, where you model objects. Instead of data and functionality being separate in the code, you can simplify many things by putting it together. It sounds simple on the surface (trust me it is simple), but some people get it so terribly wrong it makes me sad.

The premise, while an easy one for me, seems to elude many. You see, there are several implications and powerful tools this coupling of data can give us programmer types. For one, it allows us to hide the actual data and algorithms we’re using so we can change things in one piece of code without hurting other parts of the software. That alone is HUGE. We can also reuse capabilities of existing objects (we’ll call the “classes” from here on) by something known as inheritance. Inheritance is a mechanism through which a class can get the capabilities and data of another class completely for free! Then it can specialize something in order to do a specific job better. There are lots of reasons for wanting to do this.

Let’s look at the example that makes me sad. It makes me sad because it comes sooooo close to describing how to use inheritance and why you’d want it, but instead of driving the point home, it kind of drives it to the neighbors house, where they have loud parties and sleep till noon

The example is of cars, or automobiles. We’ll often start with “suppose we have a class called ‘Automobile’ that describes all the generic capabilities of an automobile.” With me so far? “Then suppose we want to describe a “Car” as inheriting from “Automobile” all those attributes plus the idea that it’s small, has four wheels and ” So far, so good. “Then we want a class for ‘Truck’…” Here’s where I start twitching. If you follow this example to the logical fruit, you basically end up having a class for every type of thing out there.

So, what’s wrong with that? Well, for one thing code tends to be easy for students to develop so they’ll take this line of thought off the bridge past the signs that say “warning” without realizing they’re doing it wrong. They don’t realize that once that code is deployed you can’t so easily go in and change it. Instead, for this car example, we should pretty much just parameterize the class “Automobile” and leave it there without any inheritance at all. That way, when Ford invents a new model of car, we don’t have to redeploy our software. If instead of “Automobile” we had “Vehicle” we could do something else. For example, we could have a class “Boat” which would describe any kind of sea faring vehicle in terms of sea faring things, “Car” that did the same for land bound vehicles, “Plane” for air born ones and so on. It’s still not a clean cut example however since we may have vehicles that are capable of land and water use or water and air, or all three. See? Examples are not so easy.

This is where the student of Object Oriented Programming needs to make that intuitive leap from swallowing and regurgitating facts and ideas, to actually understanding the intent behind them. The intent of these examples isn’t to show you where to use inheritance, it’s how. And unless you can learn the how, you’ll never understand the where. Unfortunately, so many I have come in contact with are stuck in regurgitate mode and have yet to make that leap.

Comments Off

Comments are closed.