L'interface, le contrat

Du « ça marche » au « c'est garanti »

À la leçon précédente, tu as vu des objets différents répondre au même message : Chien, Chat et Vache savent tous parler(), et la boucle les appelle sans se soucier de l'espèce. Mais une question reste en suspens : qui garantit que chaque animal sait vraiment parler ? Rien, pour l'instant. Si tu glisses un objet sans parler() dans la liste, la boucle plante.

L'interface, c'est le papier qui transforme « ça marche par chance » en « c'est garanti ». Le polymorphisme fait répondre les objets ; l'interface promet qu'ils répondront tous.

Le contrat : une liste de promesses, zéro implémentation

Pense à une prise électrique. Le mur expose deux trous à un format précis. Il ne sait pas, et ne veut pas savoir, ce que tu vas brancher : une lampe, un grille-pain, un téléphone. Tout ce qu'il exige, c'est que ta fiche respecte le format. Si elle le respecte, ça marche. C'est tout.

Une interface, c'est exactement cette prise. Elle déclare une liste de promesses (les méthodes à fournir) sans dire comment les tenir. Elle ne contient aucun code exécutable : juste les noms et la forme des méthodes attendues.

interface Notifier:
    envoyer(message)          // la promesse : QUOI, jamais COMMENT

// Chaque classe TIENT la promesse à sa façon
classe EmailNotifier implémente Notifier:
    public envoyer(message): // ... envoie un e-mail
classe SmsNotifier implémente Notifier:
    public envoyer(message): // ... envoie un SMS

L'interface Notifier ne dit rien de l'e-mail ni du SMS. Elle dit une seule chose : « tout Notifier sait envoyer(message) ». Le comment appartient à chaque classe.

Dépendre du contrat, pas de l'implémentation

Voici la vraie puissance. Imagine un service d'inscription qui doit prévenir l'utilisateur. Tu pourrais écrire ton code en dur, soudé à l'e-mail :

// ❌ Couplé en dur : Inscription connaît l'e-mail
classe Inscription:
    public sInscrire(user):
        new EmailNotifier().envoyer("Bienvenue " + user)
        // pour passer au SMS, il faut rouvrir et modifier Inscription

// ✅ Couplé au contrat : Inscription ne connaît qu'un Notifier
classe Inscription:
    privé notifier            // un Notifier, peu importe lequel
    constructeur(notifier):
        this.notifier = notifier
    public sInscrire(user):
        this.notifier.envoyer("Bienvenue " + user)

// On injecte le fournisseur qu'on veut
new Inscription(new EmailNotifier())   // par e-mail
new Inscription(new SmsNotifier())     // par SMS, sans toucher Inscription

Dans la version du bas, Inscription ne dépend plus d'un fournisseur précis : elle dépend du contrat. Tu lui branches l'e-mail, le SMS, Slack, un faux notifier pour tes tests… le service reste identique. C'est le principe qu'on répète chez les pros : « programmer une interface plutôt qu'une implémentation ». En équipe, tu entendras aussi l'anglicisme « coder contre l'interface », calqué sur l'anglais to code against (où against veut dire « en s'appuyant sur », pas « en opposition à »).

Le même mécanisme, en vrai JavaScript exécutable. Le service ignore tout du canal : il appelle juste envoyer(). Lance le code, puis ajoute une classe SlackNotifier avec sa propre méthode envoyer() et injecte-la, sans toucher la classe Inscription.

class EmailNotifier {
  envoyer(message) { return "📧 e-mail : " + message; }
}
class SmsNotifier {
  envoyer(message) { return "📱 SMS : " + message; }
}

class Inscription {
  constructor(notifier) {
    this.notifier = notifier; // un Notifier, peu importe lequel
  }
  sInscrire(user) {
    return this.notifier.envoyer("Bienvenue " + user);
  }
}

// On injecte le canal voulu, le service ne change pas
console.log(new Inscription(new EmailNotifier()).sInscrire("Alice"));
console.log(new Inscription(new SmsNotifier()).sInscrire("Bob"));

Interface ou classe abstraite ?

Les deux fixent un contrat. La différence tient en une phrase : la classe abstraite peut, en plus du contrat, livrer un bout de code déjà écrit ; l'interface, jamais.

• Interface : que des promesses. Zéro code fourni. Une classe peut en respecter plusieurs.
• Classe abstraite : des promesses plus du code commun déjà écrit, partagé par tous les enfants. Une classe n'en a qu'un seul parent.

// Classe abstraite : elle DONNE déjà du code commun
classe abstraite NotifierBase:
    public envoyer(message):       // commun à tous : on horodate
        log("[" + maintenant() + "] " + this.canal(message))
    abstraite canal(message)       // promesse : à compléter par l'enfant

classe EmailNotifier hérite NotifierBase:
    public canal(message): retourne "e-mail → " + message

Le fil qui relie tout

Reviens sur les deux leçons précédentes. La composition (leçon 5) marchait parce que la Voiture pouvait recevoir n'importe quel moteur exposant demarrer(). Le polymorphisme (leçon 6) marchait parce que la boucle faisait confiance à chaque animal pour répondre à parler().

Dans les deux cas, il y avait un contrat implicite. L'interface le rend explicite et vérifié : elle écrit noir sur blanc la promesse sur laquelle la composition et le polymorphisme s'appuient. C'est elle qui rend ces deux mécanismes sûrs : on ne croise plus les doigts en espérant que l'objet sait répondre, on l'exige par contrat.