Rails Mama’s Guide to Object Oriented Programming Part 7: Polymorphism

After a brief intermission, we now move on to the third and final pillar of Object Oriented Programming: Polymorphism.

This is part 7 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 5: Encapsulation

Part 6: Data Types

Part 7: Polymorphism

Going back to the example in Part 1, we have a problem: We’re stuck on a road trip and need to pee into an empty Coke bottle. It’s basically the same action as peeing into a toilet, but there are some major differences in how the action gets handled.

When pee goes into a toilet, it hits water, making a splash. It also changes the state of the toilet to “In need of a flush”.

When pee goes into a Coke bottle, it doesn’t hit water and the Coke Bottle can’t be flushed, but it does change the state of the Coke Bottle to “Needs to be thrown out and/or chilled in ice and passed off as Mountain Dew”.

What we need is for the Person Class to be able to send the same message “empty bladder into”  to multiple different objects (toilet, coke bottle, bidet, urinal) and get different results.

Enter the great and mighty Polymorphism!! Da-ta-da!

Polymorphism is just a big, fancy word for “the ability to send the same message to different objects and get different results.”

We’ve already talked about one way of doing this: Inheritance.

Over the next few posts, I will detail the other types of Polymorphism, but first let’s review how we could achieve Polymorphism through Single Inheritance.

In this example, I’m going to write some very simple Ruby code and explain what’s going on:

class PeeReceptacle

   def receive_pee

       puts “Thanks for the pee.”



PeeReceptacle is a Class, which you probably guessed by the word “class”. The second line defines (def) a method called receive_pee. The third line tells us what the receive_pee method will do when you call it. In this case, it will print “Thanks for the pee” to the terminal. The last two lines use “end” to close the definition of the method, and then to close the Class.

Get out the cigars, because our PeeReceptacle Class is going to have twins!

class Toilet < PeeReceptacle

   def receive_pee

      puts “Thanks for the pee. You should probably flush me before your dog comes in for a drink.”



class CokeBottle < PeeReceptacle

    def receive_pee

       puts “Thanks for the pee. I hear your boss really likes Mountain Dew.”




Congratulations PeeReceptacle! You are now a Parent Class! (Hope you didn’t like sleep.)

See how the first line of each Child Class has “< PeeReceptacle”? That means “this class inherits from PeeReceptacle”.

Our Child Classes inherit all the methods of the Parent Class, BUT if both classes have the same method defined, the method of the Child Class wins out.

That means that if we call the receive_pee method on a CokeBottle, we will get “I hear your boss really likes Mountain Dew”, but if we call the same method on Toilet, we’ll be reminded to flush.

Now all we have to do is set up a method in the Person Class called “empty_bladder_into”, and make it trigger the receive_pee method of whichever class it is used on.

BAM! Polymorphism!


Now you try!

Design another class that would inherit from PeeReceptacle. What will you call it? What will it’s receive_pee method do?

Leave a comment with your answer.

Big kudos to anyone who a) makes me laugh, b) grosses me out, or c) uses a Ruby method I’ve never seen. Enormous kudos for anyone who achieves all 3 goals.