Rails Mama’s Guide to Object Oriented Programming Part 2: Classes

This is part 2 of a series. To get the most out of these posts, read them in order:

Part 1: Objects
Part 2: Classes

In Part 1, we talked about what an Object is, and how they are useful.

In case you didn’t read it, or were distracted by all the exciting new terms for “taking a pee”, here’s a recap with some additional clarification:

In OOP (Object Oriented Programming):

  1. Instead of giving a list of step-by-step commands, we divide the program into objects and interact with those objects.
  2. Anything that can be described with a noun is an object. People, places and things are all objects.
  3. Objects have states (a.k.a attributes or properties). A toilet has a color and can be either flushed, unflushed, or clogged.
  4. Objects have actions (a.k.a. functions or methods) which they can perform. A toilet can flush or run over or smell horrid.

Now, lets look at classes.

Part 2: Classes and Inheritence

Let’s pretend you’re cleaning out your purse (or your man-purse, as the case may be). You bought one of those enormous designer bags that can be emptied out and held above your head in the case that your parachute fails to deploy, and you’ve packed it so full that you have to wheel it into the mall on a hand truck.

Now you want to smuggle a young child into the movie theatre, so you need to clear out your purse (or man-purse) to leave room for him.

You dump the contents on your table (it’s a big table), and think, “I really need to organize this junk.”

You decide to put all the objects in separate boxes with a label saying what they do, and what characteristics they have. This should make it easier to refill your parachute-man-purse with only the necessary items.


There are about 30 pens in your bag, because you are one of those people that walks off with a pen even when it has a giant, garish flower taped to it.

Making a separate box and label for each pen would take forever, so you decide that they can be grouped together.

A pen may be blue or black, ball-point or fountain, but all pens have certain things in common. All pens have the actions “write” and “run out of ink”. All pens have the states “color”, “ink type”, and “company that it belonged to”.

In OOP, “pen” is a Class, and the bank-pen with the chain still attached is an Object that belongs to the “pen” Class (and, technically, to the bank).

You grab a box and start putting all the pens in the box. It’s going pretty well until you come across a pencil. It’s not a pen, but it does pretty close to the same thing, so should it go in the pen box or should it go in it’s own box?

The pencil does have the action “write”, and it does have the state “company that it belonged to”, but it does not have ink and it cannot run out of ink.

They are so similar that it seems wasteful to use a separate box, but you still want to separate the pens and pencils.

This is where Inheritance comes in. The pens and pencils are similar because they are both “writing instruments”.

Instead of having a “pen” box and a “pencil” box, you can have a “writing instrument” box. “Writing Instrument” is the Parent Class. The sticky note on the box will describe all the methods and states that all writing instruments have in common, such as “write”.

Then, inside that box, you will wrap a rubber band around the pens and label the bunch with the methods and states that are unique to pens, such as “ink type” and “run out of ink”. You do not need to note that it can write. We already know that because everything in the “writing instrument” box has the “write” method. It says so on the sticky note.

So, now we have:

Writing Instrument (Parent Class)

methods: “write”, “get stolen from business”

states / attributes: “brand”, “original owner”

Pen (Class that Inherits From Writing Instrument)

methods: “run out of ink”

states / attributes: “ink color”

(plus all the methods & states of it’s parent class)

Pencil (Class that Inherits From Writing Instrument)

methods: “get sharpened”

states / attributes: “eraser size”, “lead type”

(plus all the methods and states of its parent class)

Now the contents of your purse are all neatly organized into Classes and Subclasses. That is…until your toddler comes around and decides to “refactor” by dumping everything on the floor.

Liked this post? See Part 3: Multiple Inheritance.

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 )

Google photo

You are commenting using your Google 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