Chaque classe que j'écris doit-elle adhérer à une interface?

J'écris un jeu en Typescript, et j'ai décidé d'aller dans le sens où j'allais essayer d'adhérer à l'idée de " programmation basée sur l'interface ", où vous écrivez du code basé sur une interface, au lieu de l'implémentation, d'un objet.

J'ai écrit un bon nombre d'interfaces et de classes qui les implémentent, puis j'ai pris du recul et j'ai réalisé que les classes étaient assez simples pour que je n'aie probablement jamais besoin de changer l'implémentation, car il n'y a vraiment qu'une seule façon de faire ce que le la classe fait (déplacer un Phaser.Sprited'une manière restreinte pour agir comme un tank).

Ensuite, je me souviens avoir lu il y a quelques années sur l'idée de YAGNI , qui est fondamentalement que vous ne devriez pas sur-concevoir votre code pour inclure des choses que vous n'utiliserez peut-être jamais.

En suivant les meilleures pratiques, chaque classe devrait-elle implémenter une interface, ou devriez-vous la limiter aux classes que vous prévoyez d'être potentiellement remplacées à l'avenir?

La raison d'avoir des interfaces est parce qu'elle simplifie le polymorphisme. Cela signifie que vous pouvez envoyer des instances par contrat plutôt que de connaître leur implémentation réelle. Par exemple, vous pouvez envoyer un "Reader" à une méthode, afin qu'une telle méthode appelée puisse utiliser sa méthode "read ()". En déclarant une interface "Reader", vous pouvez rendre tout objet conforme à ce contrat, en mettant en œuvre les méthodes qu'il précise. De cette façon, tout appelant peut supposer que certaines méthodes existeront, même si les objets sous-jacents au contrat peuvent être complètement différents.

Cela dissocie le polymorphisme d'une classe de base, et permet également entre les frontières de la chaîne de classe, en impliquant un contrat.

Maintenant ... Ceci n'est utile que si vous avez besoin de plusieurs chaînes d'héritage pour agir de la même manière, ou si vous aurez de nombreuses classes de base avec un comportement commun que vous voudrez transmettre à d'autres utilisateurs.

Si vous n'avez qu'une seule chaîne d'héritage (baseclass-> subclass) ou juste la base, ou si vous n'avez pas vraiment besoin de PASSER les objets associés à quelqu'un d'autre ou de les utiliser de manière générique, alors vous n'ajouterez pas d'implémentations d'interface, car cette notion est alors inutile.

Si vous n'êtes pas sûr d'avoir réellement besoin des interfaces, vous n'en avez probablement pas. C'est le cœur du principe YAGNI. Lorsque vous devez pouvoir échanger l'implémentation, vous introduisez une interface.

Créer une interface pour chaque classe est un peu exagéré. D'un point de vue purement orienté objet, chaque classe possède déjà une interface . Une interface n'est rien de plus que les méthodes accessibles au public et les membres de données d'une classe.

Nous utilisons généralement "interface" pour signifier "une classe Java définie à l'aide du interfacemot - clé" ou "une classe C ++ avec uniquement des fonctions virtuelles pures publiques". Ce sont des abstractions utiles, car elles dissocient l'interface d'une classe de son implémentation.

Dans cet esprit, utilisez des interfaces lorsque cela est approprié.

• Y aura-t-il plusieurs implémentations pour une interface? Si tel est le cas, cette situation peut être un candidat pour extraire des méthodes communes accessibles au public dans une interface.

• Vais-je transférer des implémentations d'une interface potentielle à d'autres modules qui ne devraient pas connaître le fonctionnement interne de mon module? Une interface peut être utile ici, car elle réduit la taille du point de contact entre les modules.

Remarquez les mots de la belette ci-dessus: "peut" être un candidat, "peut être" utile. Il n'y a pas de règle stricte et rapide qui dit «oui» ou «non» pour une situation donnée.

Cela étant dit, avoir une interface pour tout est probablement exagéré. Si vous voyez ce schéma, vous allez loin:

interface I {
  int getA()
  int getB()
  ...
  int getY()
  int getZ()
}

class C : I {
  int getA() { ... }
  int getB() { ... }
  ...
  int getY() { ... }
  int getZ() { ... }
}

Il peut être très tentant pour les nouveaux développeurs de considérer les interfaces comme un inconvénient que vous ajoutez simplement parce qu'on vous dit que c'est une "meilleure pratique". Si vous êtes en train de faire aveuglément cela, il sent la programmation culte du cargo .

Il existe un certain nombre de très bonnes raisons pour lesquelles vous devriez envisager des interfaces pour des développements plus importants plutôt que de regrouper un ensemble de classes.

Cadres moqueurs

Si vous souhaitez tester une application multicouche sans avoir à créer des objets pour les différentes couches, vous voudrez sans aucun doute utiliser des cadres de simulation pour simuler les couches. Les interfaces sont largement utilisées ici.

Injection de dépendance

Bien qu'ils soient un peu tombés en disgrâce en raison du ballonnement qu'ils ajoutent, l'idée est saine - la possibilité d'échanger simplement des concrétions basées sur une interface. Le principe peut également être trouvé dans de nombreux modèles de conception tels que le modèle d'usine.

Ces approches sont résumées dans le D à partir des principes SOLID . Le hic, c'est - utilisez des abstractions, pas des concrétions.

Comme les modèles de conception eux-mêmes, quand les utiliser est un jugement. Le point à retenir est de comprendre à quel point les interfaces sont utiles et pas seulement de les coller sur vos cours parce que vous vous sentez obligé. Il y a une bonne discussion des divers mérites de DIP et YAGNI ici .