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.

man_purse

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.

Advertisements

Rails Mama’s Guide to Object Oriented Programming Part 3: Multiple Inheritance

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

Part 1: Objects
Part 2: Classes
Part 3: Multiple Inheritance

Part 3: Single Inheritance versus Multiple Inheritance

In the first 2 sections, we talked about how in OOP, everything is an Object, and using Inheritance, one object can belong to a Class, which “inherits” the states/attributes and methods/actions of it’s Parent Class.

For example, the “Toddler Son” Class inherits the “Unconsciously Dance When Eating Something Yummy” method from the “Rails Mama” Parent Class.

But wait–the Toddler Son Class has more than one parent! It also inherits from the Anti-Geek Papi” Class. That’s where the “Love for all things with wheels” attribute comes from. The Toddler Son Class has Multiple Inheritance! 

Multiple Inheritance is just what it sounds like: one class inherits methods and states from multiple Parent Classes.

Multiple Inheritance seems pretty cool, right? If we can control what’s inherited, we can take the good parts of the Rails Mama Class (i.e. “Love of Learning”) plus the good parts of the Anti-Geek Papi Class (i.e. “Ability to Take Everything Apart and Put It Back Together with no Left-Over Parts”), and Voila! Perfect Child Class!

There is one problem, though. Rails Mama and Anti-Geek Papi both have an “Entertain Oneself” method, and those methods, though they share a name and have a similar purpose, are very different.

If we run Rails Mama’s “Entertain Oneself” method, she will go straight to the nearest computer and/or bookshelf. If we run Anti-Geek Papi’s “Entertain Oneself” method, he will start dismantling the nearest car.

If Toddler Son inherits from both Parent Classes, what will happen if we run the “Entertain Oneself” method? Will he dismantle the nearest computer? Read the car manual? Or will the program go haywire, causing him to attempt to flush the cat down the toilet?

Yes, probably the last one. Multiple Inheritance can get quite messy if used improperly, and no one wants Fluffy to take a swirl.

While some languages, (C++, Python and Perl, for example) allow Multiple Inheritance, others (Ruby, Java, and C#) spare Fluffy the bath, and stick with Single Inheritance.

If Toddler Son is an example of Multiple Inheritance, Clone Daughter is an example of Single Inheritance. She takes all of Rails Mama’s methods and states, and none of Anti-Geek Papi’s.

But if we use Single Inheritance, how do we improve on the original Class? Does Clone Daughter have to inherit the “Drive a Car in Reverse” method from Rails Mama? The world would be a much safer place if she doesn’t.

Here’s where Mixins (a.k.a Traits) come in handy.

Instead of making “Daughter” from multiple Parent Classes, we simply clone “Rails Mama” (since she’s almost perfect anyway), and then Mix In the desirable traits from “Anti-Geek Papi”.

To keep Daughter from driving like a lunatic, we would simply create a Module, or “packet of code” that contains all of Anti-Geek Papi’s driving methods, and then we mix those into the “Daughter” class.

There are different ways of doing the mixing, each unique to the language, but the basic idea is “Please don’t let my daughter inherit driving and directional sense from me.”

And that, in an oddly-misshapen nutshell, is Single versus Multiple Inheritance.

Liked this post? See Part 4: Recap & Quiz.