This week we talk about duck types and polymorphic objects.
Practical Object-Oriented Design in Ruby
A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter.
Duck types are public interfaces that are not tied to any specific class.
Objects that are defined by their behavior than by their class name.
if an object quacks like a duck and walks like a duck, then its class is immaterial, it’s a duck.
In a way, the “+” operator is a “duck type” - because it responds differently to a different type of objects.
TripCoordinator, Mechanic, Driver can all be a preparer - they all respond to the prepare method in their own ways.
At a higher level, what are these all doing? They are preparing something - we can trust within this shared interface.
Within mechanic - we only call
Instead of switching on type
Talk through this Object:
It has this insane method checking to see if the user’s notification settings match the notification that’s trying to send
We are wanting to extend the notification object, for another type - Push Notifications
Object (message, comment, like)
“The ability to tolerate ambiguity about the class of an object is the hallmark of a confident designer.”
Recognizing a duck:
“You can replace the following with ducks: • Case statements that switch on class • kind_of? and is_a? • responds_to?”
Went from a ParticipantNote, and ProgramNote, and ApplicantNote, to one single Note object through a Notable Module. They all have “ has _many: notes, as:: notable” instead of each having “program_notes”, applicant_notes, etc.
“you are missing an object, one whose public interface you have not yet discovered.”
Dot files - .zshrc - Custom prompt - with my git status -
Slippers from JP - Quadie