FondamentauxIntermédiaireSérie : Fondamentaux

Le duck typing

« Si ça marche comme un canard et que ça cancane comme un canard, c'est un canard » : le principe qui consiste à juger un objet sur ce qu'il sait faire, pas sur son type déclaré. Et son lien direct avec le typage structurel.

Par Baptiste Vidal

2 min de lecture

Mis à jour il y a 2 semaines

fondamentauxduck-typingtypagejavascriptpython

Le duck typing

Un terme rigolo pour une idée simple, très présente dans les langages dynamiques comme JavaScript ou Python.

« If it walks like a duck and it quacks like a duck, then it must be a duck. » Si ça marche comme un canard et que ça cancane comme un canard, alors c'est un canard.

# Le principe

Le duck typing consiste à ne pas se soucier du type déclaré d'un objet, mais uniquement de ce qu'il sait faire. On ne demande pas « es-tu un canard ? », on demande « sais-tu cancaner ? ».

Concrètement : si un objet possède la méthode ou la propriété dont j'ai besoin, je m'en sers - peu importe sa classe, son nom, son ascendance.

# En JavaScript

Cette fonction ne vérifie aucun type. Elle appelle .cancane() : tout objet qui a cette méthode fonctionne.

function faireParler(animal) {
  animal.cancane(); // on suppose juste que la méthode existe
}

const canard = { cancane: () => console.log("Coin !") };
const robot  = { cancane: () => console.log("Bip coin") };

faireParler(canard); // Coin !
faireParler(robot);  // Bip coin  → ce n'est pas un canard, mais il cancane

function faireParler(animal) {

  animal.cancane(); // on suppose juste que la méthode existe

const canard = { cancane: () => console.log("Coin !") };

const robot  = { cancane: () => console.log("Bip coin") };

faireParler(canard); // Coin !

faireParler(robot);  // Bip coin  → ce n'est pas un canard, mais il cancane

robot n'est pas un canard, n'hérite de rien, n'implémente aucune interface. Mais il se comporte comme ce qu'on attend, donc il passe. C'est ça, le duck typing.

# Duck typing et typage structurel : le même esprit

Le lien avec le typage structurel est direct - c'est la même intuition (« juger sur la forme, pas sur le nom »), mais à deux moments différents :

	Duck typing	Typage structurel
Où	Langages dynamiques (JS, Python)	Langages typés (TypeScript, Go)
Quand	Vérifié à l'exécution	Vérifié à la compilation
Question	« A-t-il la méthode au moment de l'appel ? »	« A-t-il la bonne forme, d'après le compilateur ? »

On peut le résumer ainsi : le typage structurel, c'est du duck typing vérifié à l'avance par le compilateur.

# Le revers de la médaille

Puisque rien n'est vérifié à l'avance, il n'y a aucune garantie. Si l'objet n'a finalement pas la méthode attendue, on ne le découvre qu'à l'exécution - par un plantage :

faireParler({ nom: "Chat" });
// 💥 TypeError: animal.cancane is not a function

faireParler({ nom: "Chat" });

// 💥 TypeError: animal.cancane is not a function

C'est le compromis classique du typage dynamique : beaucoup de souplesse, mais les erreurs se paient à l'exécution.

# À retenir

Duck typing = juger un objet sur ce qu'il sait faire, pas sur son type déclaré.
Typique des langages dynamiques (JavaScript, Python) : on suppose la méthode présente, on l'appelle.
C'est l'équivalent, à l'exécution, du typage structurel vérifié à la compilation.
Revers : aucune garantie à l'avance - un objet mal formé plante au moment de l'appel.