Qu'est-ce que le duck typing en Ruby ?

Question

Accepted Answer

**Duck typing** est un principe où l'adéquation d'un objet est déterminée par **les méthodes auxquelles il répond**, et non par sa classe ou son type — « si ça marche comme un canard et ça crie comme un canard, c'est un canard ». En Ruby, vous vous souciez de ce qu'un objet *peut faire* (il a la méthode), pas quel type il est. Cela permet un code flexible et polymorphe sans héritage ni interfaces.

## Le principe : le comportement plutôt que le 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` fonctionne avec **n'importe quel** objet qui a une méthode `quack` — un `Duck`, une `Person`, n'importe quoi. Il ne vérifie pas le type ; il appelle juste la méthode. C'est du polymorphisme sans héritage partagé ni interfaces explicites.

## Duck typing dans le monde réel

```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
```

## Vérifier le comportement (pas le 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
```

L'approche idiomatique de Ruby utilise `respond_to?` (a-t-il cette méthode ?) plutôt que `is_a?` (est-ce ce type ?) quand la flexibilité compte — en se concentrant sur la **capacité, pas la classe**.

## Pourquoi c'est important

Le duck typing est un principe fondamental de Ruby et une caractéristique déterminante de la façon dont Ruby réalise la flexibilité et le polymorphisme, donc le comprendre est important pour écrire du Ruby idiomatique.

L'idée centrale — qu'l'adéquation d'un objet est déterminée par **ce qu'il peut faire (ses méthodes), pas sa classe/son type** — permet un code flexible et polymorphe *sans* nécessiter un héritage partagé ou des interfaces explicites (contrairement aux langages typés statiquement où le polymorphisme a besoin de classes de base communes ou d'interfaces).

C'est libérateur et puissant : une méthode fonctionne avec n'importe quel objet qui répond aux méthodes nécessaires, donc vous pouvez passer n'importe quoi qui « crie » — différentes classes, objets personnalisés — et ça marche simplement, rendant le code réutilisable et adaptable.

Comprendre le duck typing explique le style flexible et orienté comportement de Ruby et pourquoi le code Ruby s'appuie typiquement sur la **présence de méthodes** (`respond_to?`) plutôt que sur les **vérifications de type** (`is_a?`) — se concentrer sur la capacité plutôt que sur la classe est l'approche idiomatique de Ruby.

Ce principe sous-tend la majorité de l'élégance de Ruby et la flexibilité de ses bibliothèques et frameworks (qui fonctionnent avec n'importe quoi fournissant les bonnes méthodes, comme n'importe quoi avec `each` ou `<<`).

Saisir le duck typing — que Ruby se soucie du comportement pas du type, permettant un polymorphisme sans interface, et que le Ruby idiomatique vérifie la capacité plutôt que la classe — est important pour écrire du Ruby flexible et idiomatique et pour comprendre la philosophie dynamique et orientée comportement qui distingue Ruby des langages typés statiquement.

C'est un sujet conceptuel fondamental qui capture la conception flexible de Ruby et un point d'entretien fréquent reflétant la compréhension de la programmation dynamique et duck-typée.