Topic 7
Topic 7
Ruby source files are converted directly from the English source tree.
Overview
Why this topic matters 💡
This topic is one of the clearest places to show what feels distinctively Ruby. Instead of centering class hierarchies or formal interfaces, students design around shared behavior and simple collaborator expectations.
Learning outcomes 🎯
By the end of this topic, students should be able to:
Assessment focus ✅
Students should be able to justify why the service depends on behavior rather than a concrete exporter class.
Short Note
Duck typing is one of Ruby's most influential design ideas. Instead of asking "what class is this object?" Ruby often asks "can this object do what I need?"
For Java developers, this can feel both freeing and risky. The educational target is not to reject interfaces blindly. It is to see when a tiny behavior contract is clear enough without extra structure.
Ruby beauty in this topic:
Ruby caution in this topic:
Reflection prompt:
Worked Examples
Example 1: Export service 💡
Exporting the same report to CSV, JSON, XML-like markup, or an external API payload is a realistic case for duck typing.
ReportService . new ( exporter : CsvExporter . new ). call ( rows ) ReportService . new ( exporter : JsonExporter . new ). call ( rows ) worked_examples.md ruby The service does not care which exporter class it receives. It cares that the object responds to export(rows) .
Example 2: Shared logging behavior 💡
Mixins are useful when multiple service objects need a small piece of shared behavior but inheritance would say the wrong thing about the domain.
Why this is useful: