Inheritance, Polymorphism, and the McDonald’s Chicken Sandwich

Explaining the Four Pillars of Object-Oriented Programming using Fast Food (pt. 2)

By now, we’ve covered how the principles of Encapsulation and Abstraction operate within a programming language like Ruby to make methods and data-management more efficient and versatile (if you haven’t read part 1 yet, catch up here).

We used simple analogies like the McDonald’s corporation to show how these mental models can improve real-world processes. Now, it’s time to cover the last two pillars of OOP — Inheritance and Polymorphism.

It’s objects all the way down…

Inheritance

Like SuperClass like SubClass.

Inheritance is one of the easier pillars to understand because there are so many similar concepts that we come across in real life.

The basics of inheritance are that a programmer can create a hierarchy of superclasses and subclasses where the “children” classes inherit all the attributes and behaviors of their “parent” classes.

Want to read this story later? Save it in Journal.

This concept allows for efficiency in class making, because sometimes we want a certain objects to have different authorities, permissions, or attributes, but it would be redundant to create an entirely new class from scratch, especially if it would end up being quite similar to an existing class.

In a web-programming context, this could boil down to something as simple as an Admin class versus a User class. The admin should be able to log-in to a website and access any of the public pages that a regular user can. The admin also has the ability to reach more private pages and even maybe block or delete users as it sees fit. The admin has a password and a username just like a regular user, but their class alone gives them more utility.

All these shapes are quadrilaterals, but the Square has the most specific properties (90° angles and equal, parallel sides)

Inheriting a McDonald’s

Ronald Jr. is a trust fund kid.

Because McDonald’s is a franchise, anyone with property space can apply to become a new McDonald’s store. If approved, they are essentially “inheriting” all of the properties of any other McDonald’s in the country.

Once a building becomes a McDonald’s, it now has access to all of the perks that McDonald’s franchisees get: corporate branding, the Big Mac secret sauce recipe, and hopefully a ball-pit!

The building still owns all of its individual traits that are special to just that building. The location, the available employee/customer pool, the square-footage, are all attributes that the building maintains, even though it inherited all these shiny new features from the clown in charge.

Now there’s a lot less work to do to make the business viable because McDonald’s has streamlined the process of what works and doesn’t work, and it can gift the fruits of that time and labor to other stores without much extra effort.

Polymorphism

This is what happens when you let wizards name things.

Polymorphism is perhaps the most confusing and complicated of the Four Pillars, which is lame because it certainly has the most interesting name!

Polymorphism comes from Greek and essentially means “able to exist in many forms”.

So what does that mean? To explain it simply, a dog can be a Best Friend, a Guard, a Bomb-Detector, or a Stray. All of those categories come with specific attributes and duties, but could all be applied to the same dog (albeit with a bit of training for some of those).

In terms of programming, polymorphism is the principle that objects from different classes can call upon the same method, but will perform different functions or produce different outcomes.

In pseudo-code:

class Vehicle
def travel
    puts "I will #{self.method_of_transport} to that destination"
end
class Car < Vehicle
def method_of_transport
    drive
end
class Boat < Vehicle
def method_of_transport
    glide on water
end
class Plane < Vehicle
def method_of_transport
    fly
end
OUTPUT:
car1.travel #=> "I will drive to that destination"
boat1.travel #=> "I will glide on water to that destination"
plane1.travel #=> "I will fly to that destination"

Planes, boats, and cars all belong to the vehicle class, but they perform different actions when asked to travel.

This could also appear in our Admin/User analogy when rendering partials. You could set a webpage to render options that are only visible to the admin (delete article, update item-list, etc.) without overpopulating your code with endless “if” statements.

Polymorphic McDonald’s

Chicken, beef, fish. In the end they’re all sandwiches.

As far as McDonald’s goes, one of their most genius ideas is to use the same basic ingredients, but put them together in a different order to create different menu items.

The McDouble, the Double Cheeseburger, the Big Mac, the Quarter-Pounder. What’s the difference? Not much, when it comes down to it. This even extends to other protein options like the McChicken or the Filet O’ Fish. Same basic structure, but the base is changed.

If we had a SuperClass called “Sandwich” we could use the principle of Polymorphism to greatly reduce the programming and processing time in creating different menu items.

Some more pseudo-code for you:

class Sandwich
def create_meal
    gather self.ingredients and package it together
end
class Big_Mac < Sandwich
@ingredients = burger, special_sauce, tomato, cheese, lettuce
class Mc_Chicken < Sandwich
@ingredients = chicken_patty, mayo, lettuce, pickles
class Filet_o_Fish < Sandwich
@ingredients = fish_patty, tartar_sauce, cheese
OUTPUT: 
big_mac1.create_meal #=> "A tasty Big Mac was created. Enjoy!"
mc_chicken1.create_meal #=> "A tasty McChicken was created. Enjoy!"
filet_o_fish1.create_meal #=> "A (not so tasty) Filet O' Fish was created. Enjoy!"

All of these sandwiches are inheriting from the Sandwich SuperClass, which allows them all to perform create_meal, but retain their specific qualities that make them unique. Inheritance and Polymorphism go together like french fries and ketchup.

Conclusions

While I personally believe that Inheritance is the OOP pillar that is most easy to visualize, it’s so closely connected to Polymorphism that they have to be explained together.

All of the four pillars (Abstraction, Encapsulation, Inheritance, Polymorphism) are mental frameworks that not only contribute to efficient runtime in your programs, but nailing down exactly how they work can make the actual writing of code much simpler and more streamlined.

There are examples in everyday life of all these concepts and I encourage you to look further and see how even seemingly simple tasks are being improved or could be improved with the implementation of these pillars.

As for me, after two articles of talking about McDonald’s, I think it’s time for a diet.

📝 Save this story in Journal.