Lessons in Ruby OOP: Duck-Typing
I remember hearing about OOP a lot throughout Launch School’s RB101 curriculum. People discussed it with hushed tones of awe. They’d remark how paradigm-shifting it was. How our lives would be changed forever. I thought they were exaggerating.
Turns out they weren’t!
Wading through RB120 and the Object-Oriented Programming paradigm was simultaneously overwhelming and eye-opening. With time and practice, though, it all made sense pretty quickly. Well. Almost all of it.
Duck-typing was one of those concepts that made perfect abstract sense but zero practical sense to me; I felt like I understood it until I tried to actually do it. I even secretly hoped that it was just one of those less important concepts that were “good to know” but don’t have to ever use.
Alas.
After only creating small games and programs, I can attest to both its importance and — honestly—helpfulness in writing clear and efficient OOP. We can do this!
Duck-Typing
If it walks like a duck and it quacks like a duck, it’s probably a duck.
So goes the adage about duck-typing. But what does this mean?
Simply this: duck-typing focuses on behavior rather than names. What does this method do? What methods are available to objects of this class? We’re interested in ability over identity. Duck-typing is meritocratic! (thanks for the fantastic word, Karl)
Let’s back up a minute, first. Duck-typing is a kind of polymorphism. Polymorphism is the ability of different objects to respond in different ways to the same message (or sometimes even for different objects to respond in the same way to the same message — like with instance methods accessed through class inheritance that are not overwritten!). Class inheritance and interface inheritance (module mix-ins) are one way to accomplish polymorphism. Duck-typing is another.
Let’s look at the following example:
Here we have four classes of different animals that each have an instance method with the same exact name: speak. Because it has the same name, we might be inclined to think it is the same instance method, but it’s not. Notice how each of the speak methods have a different implementation: they each return a completely different string.
On lines 27-29, we use an each method to invoke the speak method on an object from each of our four classes. Even though we invoke the seemingly same method on each object, we get a completely different output. Why? Duck-typing. Each object has access to a method called speak (albeit a different method), and we’re interested in what that speak method can do for us.
By doing it this way, we can have a very simple each method that can output appropriate response for different types of objects.
I hope this was helpful. If you’re an LS student and want to talk through these concepts or anything else in OOP, feel free to reach out to me on Slack! Onwards and upwards, fellow learners.
