Le duck typing, ou réponds-tu au message ? Duck typing, or do you answer the message?

Ne demande pas qui tu es. Demande si tu réponds.Don't ask what you are. Ask whether you respond.

Deux volumes durant, on a envoyé des messages sans jamais demander le type de personne. C'était le sujet sans le nommer. Le voici : le duck typing. « Si ça marche comme un canard et que ça cancane comme un canard, c'est un canard. » Une méthode qui appelle x.quack fonctionne sur n'importe quel objet répondant à quack — sans interface à implémenter, sans superclasse commune. Le seul contrat, c'est le message lui-même.For two volumes we've sent messages without ever asking anyone's type. That was the subject, unnamed. Here it is: duck typing. 'If it walks like a duck and quacks like a duck, it's a duck.' A method calling x.quack works on any object responding to quack — no interface to implement, no shared superclass. The only contract is the message itself.

def faire_crier(x) = x.quack   # j'envoie juste le message quack

class Canard;   def quack = "Coin !"      end
class Klaxon;   def quack = "POUET !"     end   # aucun lien avec Canard
class FauxCanard; def quack = "(silence)" end   # un objet de test

faire_crier(Canard.new)     # => "Coin !"
faire_crier(Klaxon.new)     # => "POUET !"
faire_crier(FauxCanard.new) # => "(silence)"
# aucune interface, aucune superclasse commune : il suffit de répondre

Ailleurs, il faut déclarer qu'on est compatible. Ici, il suffit de l'être.Elsewhere, you must declare you're compatible. Here, it's enough to be so.

Dans un langage statique, pour que deux classes soient interchangeables, elles doivent partager un type déclaré : une interface implements, une superclasse commune. Un objet qui aurait pourtant la bonne méthode mais sans la déclaration est refusé. Ruby renverse la priorité : le comportement prime sur le type. Si tu réponds au message, tu passes — qui que tu sois.In a static language, for two classes to be interchangeable, they must share a declared type: an interface implements, a common superclass. An object that has the right method but lacks the declaration is rejected. Ruby flips the priority: behavior trumps type. If you answer the message, you pass — whoever you are.

// Java : pour être interchangeables, il FAUT un type commun déclaré
interface Quackable { String quack(); }

class Duck   implements Quackable { public String quack() { return "Coin"; } }
class Klaxon implements Quackable { public String quack() { return "Pouet"; } }

void shout(Quackable q) { System.out.println(q.quack()); }
// un objet qui aurait pourtant un quack() mais n'implémente PAS
// Quackable serait REFUSÉ à la compilation. Le type prime sur le comportement.

Pour être acceptés par shout, Duck et Klaxon doivent déclarer qu'ils sont Quackable. Un objet d'une lib tierce, avec un quack() parfait mais sans cette déclaration, est rejeté. Le type prime sur le comportement.To be accepted by shout, Duck and Klaxon must declare they're Quackable. An object from a third-party lib, with a perfect quack() but no such declaration, is rejected. Type trumps behavior.

respond_to? interroge le message. is_a? interroge le type.respond_to? asks about the message. is_a? asks about the type.

Le duck typing ne veut pas dire « ne jamais rien vérifier ». Il veut dire vérifier la bonne chose. respond_to?(:each) demande « sais-tu faire each ? » — une question sur le comportement. is_a?(Array) demande « es-tu de ce type ? » — une question sur l'identité, plus rigide. La première colle au protocole ; la seconde lie ton code à une classe précise. Et le vrai bonus tombe en test : un objet qui répond au message remplace n'importe quel mock.Duck typing doesn't mean 'never check anything'. It means check the right thing. respond_to?(:each) asks 'can you do each?' — a question about behavior. is_a?(Array) asks 'are you this type?' — a question about identity, more rigid. The first sticks to the protocol; the second ties your code to a precise class. And the real bonus lands in testing: an object that answers the message replaces any mock.

# Une méthode qui n'exige qu'un protocole : "répondre à <<"
def log_into(sink, message)
  sink << "[#{Time.now}] #{message}\n"   # le seul message attendu : <<
end

log_into($stdout, "démarré")      # un IO
log_into(File.open("a.log", "a"), "ok")
require "stringio"                # pas chargé par défaut
log_into(StringIO.new, "en mémoire")
log_into([], "dans un tableau")   # Array répond aussi à <<
# quatre types sans parenté, un seul protocole accepté

# Le bonus : tester sans framework de mock — un objet qui répond, c'est tout
class FakeSink
  attr_reader :lines
  def initialize = @lines = []
  def <<(s) = @lines << s        # il suffit de répondre à <<
end

sink = FakeSink.new
log_into(sink, "salut")
sink.lines.first                 # => "[…] salut\n"
# pas de double, pas de stub : un vrai petit objet qui répond au message

Le is_a? « par sécurité » rejette des objets qui savaient répondre.The "just-in-case" is_a? rejects objects that knew how to respond.

Venant d'un langage à types, le réflexe rassurant est de vérifier la classe en entrée : « il me faut un Array ». Mais ta méthode n'avait pas besoin d'un Array — elle avait besoin d'un each. En exigeant le type, tu refuses un Range, un Set, un Enumerator paresseux : des objets parfaitement capables de faire ce que tu demandes. Tu as recréé à la main le système de types rigide que Ruby venait d'éviter, en pire — car le tien ne connaît que les classes que tu as pensé à lister.Coming from a typed language, the reassuring reflex is to check the class on input: 'I need an Array'. But your method didn't need an Array — it needed an each. By demanding the type, you reject a Range, a Set, a lazy Enumerator: objects perfectly able to do what you ask. You've hand-rebuilt the rigid type system Ruby just avoided, but worse — because yours only knows the classes you thought to list.

# Le réflexe importé d'un langage statique : "je vérifie le type d'abord"
def somme(collection)
  raise ArgumentError, "il me faut un Array" unless collection.is_a?(Array)
  collection.reduce(0, :+)
end

somme([1, 2, 3])        # => 6
somme(1..3)             # ArgumentError — alors qu'un Range sait reduce !
somme(Set[1, 2, 3])     # ArgumentError — un Set aussi
somme(lazy_enum)        # ArgumentError — et un Enumerator paresseux aussi
# tu as REJETÉ des objets parfaitement valides au nom d'un type

# Le correctif : n'exige que le protocole dont tu te sers vraiment
def somme(collection)
  collection.reduce(0, :+)    # reduce n'a besoin que de each
end

somme([1, 2, 3])        # => 6
somme(1..3)             # => 6
somme(Set[1, 2, 3])     # => 6

# et SI tu dois vraiment garder une frontière, teste le COMPORTEMENT :
raise ArgumentError unless collection.respond_to?(:each)