What is duck typing in Ruby?

Question

Accepted Answer

**Duck typing** is a principle where an object's suitability is determined by **what methods it responds to**, not its class or type — "if it walks like a duck and quacks like a duck, it's a duck." In Ruby, you care that an object *can do* something (has the method), not what type it is. This enables flexible, polymorphic code without inheritance or interfaces.

## The principle: behavior over type

```ruby
# this method works with ANY object that has a `quack` method —
# regardless of its class. No interface or inheritance required.
def make_it_quack(duck)
  duck.quack            # only cares that `duck` responds to `quack`
end

class Duck
  def quack = "Quack!"
end
class Person
  def quack = "I'm imitating a duck!"
end

make_it_quack(Duck.new)     # "Quack!"
make_it_quack(Person.new)   # "I'm imitating a duck!" — works! (it has quack)
```

`make_it_quack` works with **any** object that has a `quack` method — a `Duck`, a `Person`, anything. It doesn't check the type; it just calls the method. This is polymorphism without shared inheritance or explicit interfaces.

## Real-world duck typing

```ruby
# Ruby code typically relies on method presence, not type checks
def process(items)
  items.each { |i| puts i }   # works with ANY object that has `each`
  # → an Array, a Set, a Range, a custom Enumerable... all "quack" with each
end

# the << operator: works on anything that defines it
def append_to(collection, item)
  collection << item          # works on Array, String, IO, Logger... they all have <<
end
```

## Checking for behavior (not type)

```ruby
# ✅ duck-typed — check if it responds to a method (behavior)
if obj.respond_to?(:each)
  obj.each { ... }
end

# ❌ less Ruby-like — checking the class/type
if obj.is_a?(Array)   # rigid; duck typing prefers checking capability
end
```

Idiomatic Ruby uses `respond_to?` (does it have this method?) over `is_a?` (is it this type?) when flexibility matters — focusing on **capability, not class**.

## Why it matters

Duck typing is a fundamental Ruby principle and a defining characteristic of how Ruby achieves flexibility and polymorphism, so understanding it is important for writing idiomatic Ruby.

The core idea — that an object's suitability is determined by **what it can do (its methods), not its class/type** — enables flexible, polymorphic code *without* requiring shared inheritance or explicit interfaces (unlike statically-typed languages where polymorphism needs common base classes or interfaces).

This is liberating and powerful: a method works with any object that responds to the needed methods, so you can pass in anything that "quacks" — different classes, custom objects — and it just works, making code reusable and adaptable.

Understanding duck typing explains Ruby's flexible, behavior-focused style and why Ruby code typically relies on **method presence** (`respond_to?`) rather than **type checks** (`is_a?`) — focusing on capability over class is the idiomatic Ruby approach.

This principle underpins much of Ruby's elegance and the flexibility of its libraries and frameworks (which work with anything providing the right methods, like anything with `each` or `<<`).

Grasping duck typing — that Ruby cares about behavior not type, enabling interface-free polymorphism, and that idiomatic Ruby checks capability rather than class — is important for writing flexible, idiomatic Ruby and for understanding the dynamic, behavior-oriented philosophy that distinguishes Ruby from statically-typed languages.

It's a core conceptual topic that captures Ruby's flexible design and a frequent interview point reflecting understanding of dynamic, duck-typed programming.