Rails Mama’s Guide To Object Oriented Programming: Part 1

After my first few interviews for Junior Developer positions, I have seen that some of the hardest questions for me to answer are the ones that ask me to explain a concept in object-oriented programming.

In some cases, it’s because I’m not familiar with the concept, but in many cases, it’s simply that translating my practical experience with those concepts into words–especially words that don’t make me sound like an idiot–can be incredibly difficult.

I decided to research the concepts a bit more, and found that most resources give overly-technical definitions that are not useful to a beginner.

With that in mind, I’ve decided to create a multi-part series explaining OOP (Object Oriented Programming) in beginner-friendly terms.

So, with no further ado….

Part 1: Object Oriented Programming versus Procedural Programming

Have you ever played The Sims? How about Zelda? World of Warcraft?

Imagine if, instead of clicking on an ogre to fight it, or a toilet to pee in it, you had to choose an action from a giant list of commands.

In the Sims, you might be in the kitchen, but you would still have the option to “Flush the Toilet”. Worse, if you are in the bathroom, you would have so many irrelevant commands in your menu that by the time you found the “Take a Whiz” command, it would be too late. There would be a puddle on the floor, and you’d be searching for a “Take a Shower” command.


That’s Procedural Programming. Some of the most popular Procedural languages are Fortran, COBOL and C, all created in the 60’s and 70’s.

In Procedural Programming, you give the computer a list of steps that it will take one by one, in order. Any procedure might be called at any point in the program, so if I write my program to 1) go to sleep in the bed and then 2) go pee, the program will not care that I forgot to write “Walk to the bathroom.” Oops–time to add a “Change the sheets” command.

Now, imagine if the player had the ability to create new commands. Your Sim REALLY has to pee, and you can’t find a “Take a Whiz” command, so you create one. You don’t realize that there’s already a “Tinkle” command that does the exact same thing, so you’ve just added an unnecessary command, cluttering up the menu even more. Worse, there are a hundred other users creating things like “Flush my Buffers” and “Do a Wee”. Your action menu is getting fatter by the second!

Then somebody came along and said, “Stop!” We’re going to organize these menus by object. Everything’s an object now: you’re an object, I’m an object, the toilet’s an object–everything. Each of those objects will have its own menu of actions (a.k.a functions or methods). It will also have states (a.k.a properties or attributes), so that a toilet can be clean or dirty, white or blue, empty or clogged.

Now, you can only pee by clicking on the toilet. If you click on the sink, you will not get a “Take a whiz” option, because that’s just nasty.

Now that your actions are organized, it’s easy to see that you have 100 methods for “Drain The Sleepy Weazel”, and you can pick one and delete the rest. No more puddles on the floor.

That’s Object Oriented Programming. C++, Java, Python, Ruby and PHP are examples of object-oriented languages.

Of course, the world of Object Oriented Programming is not perfect.

In a traditional Object-Oriented language, like Java, every object must be part of a Class. A class is just a group of similar objects that share methods (actions) and states (properties or attributes).

Sometimes it’s easy to figure out what Class an object should belong to. Clearly, that round white bowl that you are peeing into is part of the “Toilet” class.

And what about the Bidet, or the Urinal? You pee into it, and it can be clean or dirty, clogged or unclogged. It shares many of the same actions and attributes, so it should probably still be part of the Toilet class.

But what if you’re on a long car ride and have to pee into an empty Coca Cola bottle? Should that bottle be part of the Toilet class, since you’re peeing into it, or should you create a Soda Bottle class, even though you would normally think of a Soda Bottle as something you would drink out of, not pee in.

This is where things get complicated with Object Oriented Programming, but luckily there are several techniques for dealing with these conundrums, which I will address in a later blog post.

 Liked this post? See Part 2: Classes.

One thought on “Rails Mama’s Guide To Object Oriented Programming: Part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s