Les interfaces existent pour prendre en charge un comportement spécifique

« Bonjour, Amigo ! Aujourd'hui, j'aimerais t'expliquer pourquoi les interfaces existent. Tu entendras souvent qu'une classe, un objet ou une entité prend en charge une interface particulière. Mais qu'est-ce que ça veut dire, prendre en charge une interface ? »

Dans un sens plus large, toute interface est un mécanisme définissant comment une chose interagit avec une autre. Par exemple, une télécommande de télé est une interface de commande à distance. Un chien comprend et exécute des ordres, ce qui signifie que le chien prend en charge une interface vocale (les ordres). Pour résumer, on peut dire qu'une interface est la manière normalisée dont deux choses interagissent, où les deux parties connaissent la norme. Quand une personne dit « assis » à un chien, son ordre fait partie d'une « interface ordres oraux pour chien », et si le chien obéit à l'ordre, alors nous disons que le chien prend en charge l'interface.

Il en va de même en programmation. Les méthodes sont des actions effectuées sur un objet, sur ses données. Et si une classe implémente certaines méthodes, elle « prend en charge l'exécution » de certaines commandes. Que gagnons-nous en combinant les méthodes dans une interface ?

1) Chaque interface, de la même façon qu'une classe, a un nom unique. Les deux parties peuvent être sûres à 100 % que l'autre partie prend en charge l'interface exacte qu'elles connaissent, et pas une interface similaire.

2) Chaque interface impose certaines restrictions sur une classe qui va la prendre en charge. La classe (son développeur) décide ce qu'elle fera lorsque les méthodes héritées d'une interface sont appelées, mais le résultat doit être dans les limites des attentes raisonnables. Si nous disons à un chien « assis » et qu'il bougeotte pendant 5 secondes, puis s'assoit, il prend en charge l'interface. Mais s'il t'attrape par la jambe à la place, alors on ne peut pas dire qu'il prend en charge l'interface. L'exécution de la commande n'a pas produit le résultat escompté.

Supposons que toi et tes amis écrivez un jeu vidéo. On te demande de programmer le comportement d'un personnage. Un de tes collègues a déjà écrit le code pour afficher tous les personnages à l'écran. Un deuxième collègue, qui est responsable de la sauvegarde du jeu sur le disque, a écrit le code pour enregistrer tous les objets du jeu dans un fichier. Chacun d'eux a écrit beaucoup de code et fait une interface pour interagir avec ce code. Par exemple, cela pourrait ressembler à ceci :

interface Saveable
{
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
}

interface Drawable
{
 void draw(Screen screen);
}

class PacMan implements Saveable, Drawable
{
…
}

En d'autres termes, pour prendre en charge une interface (ou un groupe d'interfaces), ta classe doit :

1) En hériter

2) Implémenter les méthodes qui y sont déclarées

3) Faire accomplir aux méthodes ce qu'elles sont censées réaliser.

Ainsi, le reste du code du programme, qui ne sait rien au sujet de ta classe et de ses objets, peut travailler avec ta classe.

« Pourquoi le code ne peut-il rien savoir sur ma classe ? »

« Disons que tu as pris le code d'un programme que quelqu'un a écrit il y a un an. Ou supposons que tes amis ont acheté/utilisent sous licence le moteur de jeu de quelqu'un d'autre. Tu as un code fonctionnel pour le jeu. Des milliers d'objets qui interagissent les uns avec les autres. Et ils peuvent facilement interagir correctement avec tes objets si cette interaction se produit grâce aux interfaces que tes classes ont correctement implémentées. »

« Ça alors ! Je ne savais pas que c'était possible. »

« Tous les grands projets fonctionnent comme cela. Les gens ont cessé d'écrire à partir de zéro il y a longtemps. »

Les gens ne réinventent également pas les mathématiques et l'alphabet à chaque fois. Au lieu de cela, ils étudient tout ce qui a été inventé avant eux.