I’ve been reading Steve McConnell’s “Code Complete 2″. It’s been called “The Joy of Cooking” for programmers (by Jeff Atwood of codinghorror.com, whose blog happens to be named after a concept in the book). It is very good.

I know a little about Object Oriented Programming. I’ve read a few books on the topic and used it real world on several projects. But I was pleasantly surprised to learn something major about it that I’d never thought of before in Chapter 5 of “Code Complete 2″.

I’m going to stop here, and briefly explain an object for those of you who don’t know. An object is like a sausage grinder. You put some meat and seasonings in the top, some magic happens, you get sausage out. Procedural programming could be said to be like taking the meat, cutting it in very specific ways and adding the seasonings in specific ways, and making sausage by hand. With OO, your grinder knows how to make the meat, but your other code never sees this happen. I’m not good at explaining this, because with procedural, you could just use a function to grind the meat. Anyways, read on…

According to McConnell (What a name pattern btw, single letter, double letter, single letter, double letter, single letter, double letter…) Objects are like icebergs. The parts you see, the parts your code interfaces with, are just the very tip.

The point of this, is that if you need to completely change how the grinder works to make the meat, it doesn’t effect the way you use it. You still put the meat in, magic happens, meat comes out. With procedural programming, you have to re-learn how to cut the meat, and when to add the seasonings.

All this is just old hat to me. I’m reading McConnell’s stuff, and I’m not necessarily bored, but I already know it. His example is much more real world specific:

What if you have an Student, and you need to give them an id. What if you give them an id by incrementing it. If you spread id++ all through your code, and then your boss says “no no no. Ids increment by two!”. So you go through the code and change all the id incrementation to id+=2. Then your boss says “no no no! Ids increment by two… But only on Wednesday!”. So now you write a function. You put id=newId() in your code. Good job! That’s step 1 towards thinking OO. Abstraction. Then you show your boss, and you find out “No no no! Ids aren’t ints! Ids are strings!”. Wait, what?

This is where it gets new to me. Because as soon as your boss changes the type of variable id is, all of my code would be invalid because I’ve done this:

int id = Student.newId();

When I should have done is:

Id id = Student.newId();

Now it doesn’t matter what type the id is. My boss can change the Id type all day long. He can make it a hash table for all I care. He can even go so far as to say, when I get a new student Id, I have to take their name, concatenate their birthday, md5 encrypt it, and reverse the whole thing, and I don’t care. Because I have all of that functionality hidden inside the newId() method for my student, and it returns the String/int/hash/whatever as the type Id, which I define to be anything I want in just one place. That’s what OOP is about. That’s true abstraction and information hiding.

Thanks McConnell. I apologize if this post meant nothing to any of you. I was amazed by it, and wanted to make note of it for myself, as well as hopefully enlightening a few fellow programmers (who probably already knew this though).