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.
Preparer
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 prepare_trip vs gas_up or full_water_tank-
Instead of switching on type
You
Talk through this Object:
Notification Object?
https://github.com/withbetterco/wellstart/blob/master/app/models/notification.rb#L156
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)
User
NotificationSettings
Notifier
Notification Policy
“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?”
Polymorphic Objects
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