Rails Mama’s Guide to Object Oriented Programming Part 4: Recap

This is part 4 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 4: Recap & Quiz

Part 4: Review of Objects, Classes and Inheritance

We’ve been over several Object Oriented Programming (OOP) concepts in the last 3 posts, so it’s time to recap and take a quiz!

Let’s combine all of those concepts by imagining a program that would help Santa deliver presents.

A Function (or Method) might look something like this:

Deliver Present From Deliverer To Recipient

Procedural Programming is just a list of step-by-step instructions. If you say, “Deliver Elf From Present to Child”, the program says, “Yes, ma’am!” and you have a child wondering why a present just gave him an elf.

That would be awkward, so we’re going to use OOP instead. That will allow us to treat each noun as an object, and restrict what those objects can and can’t do.

First, let’s make our list of Objects:

  1. Santa
  2. Elfie the Elf
  3. Buddy the Elf
  4. Toy Car
  5. Rag Doll
  6. Little Jimmy
  7. Little Janey
  8. Jolly the Elf-Child

Now, let’s break those Objects down into Classes:

  1. Deliverers: Santa, Elfie, Buddy
  2. Presents: Car, Doll
  3. Recipients: Jimmy, Janey, Jolly the Elf-Child

These classes work fine for our current method, but what if we add more methods like “Choose Recipient for Present” or “Make Present”? We don’t want Santa making presents (never give him a hammer), and we don’t want elves making decisions about presents (Wooden shoes for everyone!).

We also don’t want to have to write all our delivery-related methods twice, and imagine if we get desperate and have to start using reindeers and snowmen to make deliveries as well? We’re going to be re-writing the same methods over and over!

It’s time to make some sub-classes using Inheritance.

Parent Class: Deliverers

Methods: “pick up present”, “go down chimney”, “place present under tree”

Elf Class (Inherits from Deliverer Class)

Methods: Deliverer methods + “Make presents”

Santa Class (Inherits from Deliverer Class)

Methods: Deliverer methods + “Choose Recipient for Present” + “Say ‘Ho ho ho!'”

Now let’s look at Elfie. Elfie is an Elf, and Elves are Deliverers. That means Elfie is an Elf AND a Deliverer.

But what about Jolly the Elf-Child?

Jolly can receive presents, because he is a child, but when the workshop is behind schedule, Santa might need him as a deliverer or toy-builder too. How do we handle that?

One way is through Multiple Inheritance. Jolly can Inherit from both the Elf Class and the Child Class. But…remember how that can get messy if they have different methods with the same name?

Let’s use Single Inheritance instead.

We’ll create an Elf-Child class that inherits from Elf, and make a Module with the important Child methods.

Module methods: “receive presents”, “flip out over presents”, “believe in Santa”

That module is a “Mixin”, because we are “mixing it into” a class it would not normally be part of.

Now You Try:

(No wrong answers, just exercises in thought):

Mrs. Claus can deliver presents, make decisions about who receives presents, and also bake cookies.

  1. In the above situation, what are the Objects?
  2. What Methods Does Mrs. Claus have?
  3. Would she belong to an existing class, or would you create a new class?
  4. With Multiple Inheritance, what classes could a Mrs. Claus Class inherit from?
  5. If you used Multiple Inheritance, what methods could overlap between those Parent Classes (for example, could a child and an elf sleep differently?)
  6. With Single Inheritance, what one class would you choose for Mrs. Claus to inherit from?
  7. What other methods would you “Mix in”?

Feel free to leave a comment with your take on the answers to these questions. I’ll be happy to give you feedback.

However, to be fair to yourself and others, please:

  • Answer the questions for yourself before reading others’ answers
  • If you comment on someone else’s answer, please make sure it is “constructive criticism” (Instead of saying “You’re wrong!”, nicely explain how the answer could have been improved in your humble opinion.) 

We are all Big Kids here, and I do not want to have to put any commenters in Time Out.

Want to Learn More? See Part 5: Encapsulation

Advertisements

4 thoughts on “Rails Mama’s Guide to Object Oriented Programming Part 4: Recap

  1. In the interests of getting this started:
    1. Mrs Claus & Cookies
    2. Deliverer methods + “Choose recipient for present” + “Bake cookies”
    3. New “Mrs Claus class (inherits from Deliverer Class)”
    4. Deliverer Class and Santa Class (?)
    5. If 4 is true then Deliverer methods (?)
    6. Deliverer Class
    7. “Choose recipients” module

    Liked by 1 person

  2. “In the above situation, what are the Objects?”
    ~ Mrs. Claus is the only obvious object. Until we build out the cookie feature we don’t need to build an object for them.

    “What Methods Does Mrs. Claus have?”
    ~ Pick Up Present, Go Down Chimney, Place Present Under Tree, Choose Recipient for Present, and Bake Cookies.

    “Would she belong to an existing class, or would you create a new class?”
    ~She would need a new class since no existing class can Bake Cookies and it doesn’t make sense to give that method to any existing class

    “With Multiple Inheritance, what classes could a Mrs. Claus Class inherit from?”
    ~ MI doesn’t seem to be required here. Mrs. Claus requires the Choose Recipient for Present method which is only available in the Santa class and that class already gets all the deliverer methods. Any way you try to get the Choose Recipient for Present method (assuming DRY, Dont Repeat Yourself, methodology) you’ll also get the Say Ho Ho Ho method so it’s reasonable to just subclass Santa. Unless you consider refactoring as described below.

    “If you used Multiple Inheritance, what methods could overlap between those Parent Classes (for example, could a child and an elf sleep differently?)”
    ~ I don’t see any need for MI yet. When we start building the Receives Cookies method we might consider creating a Cookie Eater class or adding it to the Receiver class and then we have to start thinking about MI

    “With Single Inheritance, what one class would you choose for Mrs. Claus to inherit from?
    What other methods would you “Mix in”?”
    ~ Mrs. Claus could inherit from Santa (woah…) in order to get the Choose Recipient for Present method. A better idea though would be refactoring the Santa class by pulling the Choose Recipient for Present method into a Claus class that Santa and Mrs would then inherit from. Santa can define Say Ho Ho Ho and Mrs can define Bakes Cookies.

    You could also have Mrs. Claus inherit from Deliverers and mix in the Choose Recipient for Present method from Santa. Any significant program logic offers a multitude of implementation possibilities. 🙂 Which route seems best will depend on the language you’re using, your personal aesthetic, and the phase of the moon.

    Liked by 1 person

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 )

Google+ photo

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

Connecting to %s