Quel est le raisonnement derrière le principe de ségrégation des interfaces ?

Question

Le principe de ségrégation des interfaces (ISP) indique que de nombreuses interfaces spécifiques au client sont meilleures qu'une interface à usage général.Pourquoi est-ce important?

Answer 1

Le FAI déclare que :

Les clients ne doivent pas être obligés de dépendre des méthodes qu'ils n'utilisent pas.

Le FAI se rapporte à des caractéristiques importantes - cohésion et couplage.
Idéalement, vos composants doivent être hautement personnalisés.Il améliore la robustesse et la maintenabilité du code.

L'application du FAI vous offre les bonus suivants :

• Haut cohésion - meilleure compréhensibilité, robustesse
• Faible couplage - meilleure maintenabilité, haute résistance aux changements

Si vous souhaitez en savoir plus sur les principes de conception des logiciels, obtenez une copie de Développement de logiciels agiles, principes, modèles et pratiques livre.

Answer 2

La ségrégation d'interface est le « I » sur le principe SOLID, avant d'approfondir avec le premier, expliquons ce que signifie le second.

SOLID peut être considéré comme un ensemble de bonnes pratiques et de recommandations formulées par des experts (c'est-à-dire qu'elles ont déjà fait leurs preuves) afin de fournir une base fiable dans la façon dont nous concevons des applications.Ces pratiques visent à faciliter la maintenance, l'extension, l'adaptation et la mise à l'échelle de nos applications.

Pourquoi devrais-je me soucier de la programmation SOLID ?

Tout d’abord, vous devez réaliser que vous ne resterez pas éternellement là où vous êtes.Si nous utilisons des standards et des architectures bien connues, nous pouvons être sûrs que notre code sera facile à maintenir par d'autres développeurs qui nous succéderont, et je suis sûr que vous ne voudriez pas vous occuper de la tâche de corriger un code qui n'a pas fonctionné. Je n'ai appliqué aucune méthodologie connue car il serait très difficile de la comprendre.

Le principe de ségrégation des interfaces.

Sachez que nous savons quels sont les principes SOLID, nous pouvons entrer plus en détail sur le principe de ségrégation d'interface, mais que dit exactement la ségrégation d'interface ?

«Les clients ne devraient pas être obligés de mettre en œuvre des méthodes inutiles qu'ils n'utiliseront pas»

Cela signifie que parfois nous avons tendance à créer des interfaces avec beaucoup de méthodes, ce qui peut être bon dans une certaine mesure, mais cela peut facilement être abusé, et nous pouvons nous retrouver avec des classes qui implémentent des méthodes vides ou inutiles, ce qui bien sûr ajoute du code et du fardeau supplémentaires. à nos applications.Imaginez que vous déclarez beaucoup de méthodes dans une seule interface, si vous aimez les aides visuelles, une classe qui implémente une interface mais qui a vraiment besoin de quelques méthodes ressemblerait à ceci :

D'un autre côté, si vous appliquez correctement la ségrégation des interfaces et divisez votre interface en sous-ensembles plus petits, vous pouvez être sûr d'implémenter ceux qui sont uniquement nécessaires :

Voir!C'est bien mieux !L'application de ce principe vous permettra d'avoir un faible couplage qui contribue à une meilleure maintenabilité et une haute résistance aux changements.Vous pouvez donc vraiment tirer parti de l’utilisation des interfaces et implémenter les méthodes lorsque vous le devriez vraiment.Passons maintenant en revue un exemple moins abstrait, disons que vous avez déclaré une interface appelée Reportable

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

Et vous avez un client qui va uniquement exporter certaines données au format Excel, vous pouvez implémenter l'interface, mais n'auriez-vous qu'à implémenter la méthode Excel ?La réponse est non, vous devrez coder l'implémentation de toutes les méthodes même si vous n'allez pas les utiliser, cela peut provoquer beaucoup de code indésirable, rendant ainsi le code difficile à maintenir.

N'oubliez pas de rester simple et de ne pas vous répéter et vous constaterez que vous utilisez déjà ce principe sans le savoir.

Answer 3

Il simplifie l'interface que n'importe quel client utilisera et supprime les dépendances qu'il pourrait autrement développer sur des parties de l'interface dont il n'a pas besoin.

Answer 4

L'une des raisons est que le fait d'avoir de nombreuses interfaces avec un nombre minimal de méthodes pour chacune facilite l'implémentation de chaque interface et leur implémentation correcte.Une grande interface peut être indisciplinée.De plus, l'utilisation d'une interface ciblée dans un scénario rend le code plus maintenable car vous pouvez voir quelle facette de l'objet est utilisée (par exemple, une interface IComparable vous permet de savoir que l'objet est uniquement utilisé à des fins de comparaison dans le scénario donné).

Answer 5

Ce principe répond avant tout à un double objectif

• Pour rendre le code plus lisible et gérable.

• Favorise la responsabilité unique des classes (forte cohésion).Bien sûr, pourquoi une classe devrait-elle avoir une méthode qui n’a aucun impact sur le comportement ?Pourquoi ne pas simplement le supprimer.C'est à cela que sert le FAI

Il y a peu de questions qu'un concepteur doit poser lorsqu'il s'adresse au FAI

• Que réalise-t-on avec le FAI
• Comment analyser un code déjà existant pour détecter toute violation du FAI

Pour pousser cette discussion plus loin, je dois également ajouter que ce principe n'est pas un « principe » au sens le plus strict, car dans certaines circonstances, appliquer ISP à la conception, au lieu de favoriser la lisibilité, pourrait rendre la structure de l'objet illisible et encombrée d'informations. code inutile.Vous pouvez très bien observer cela dans le package java.awt.event

Plus sur mon blog : http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

Answer 6

FAI est important.

Idée de base du FAI :Le client ne doit pas être obligé de dépendre de méthodes qu’il n’utilise pas.

Ce principe semble plus logique.Idéalement, le client ne devrait pas implémenter les méthodes qui ne sont pas utilisées par le client.

Reportez-vous à la question SE ci-dessous pour un exemple de code :

Principe de ségrégation d'interface - Programme vers une interface

Avantages :

1. La flexibilité :En l'absence de FAI, vous disposez d'une interface FAT générique et de nombreuses classes l'implémentant.Supposons que vous ayez 1 interface et 50 classes.S'il y a un changement d'interface, les 50 classes doivent changer leur implémentation.

   Avec le FAI, vous diviserez l’interface FAT générique en petites interfaces finement granulaires.S'il y a un changement dans l'interface granulaire petite, seules les classes implémentant cette interface seront affectées.

2. Maintenabilité et facilité d'utilisation:Étant donné que les modifications sont limitées à une interface granulaire fine au lieu d’une interface FACT générique, la maintenance du code est plus facile.Le code sans rapport ne fait plus partie des classes d'implémentation.

Answer 7

Pour éviter les efforts de régression, lorsqu'un seul changement spécifique au client ou au comportement est spécifique.Si vous avez combiné toutes vos méthodes de comportement dans une GRANDE interface, pensez simplement à la façon dont vous finirez par tester tous les morceaux de code où tout ce à quoi vous avez fait référence est cette interface, même lorsque seuls de petits changements se sont produits.

Pour une explication plus détaillée, reportez-vous à Article sur le principe de ségrégation des interfaces

Answer 8

L'article de Robert Martin sur le sujet donne une explication moins souvent évoquée :

La force vers l'arrière appliquée par les clients sur les interfaces.

Si deux classes dépendent directement de deux méthodes différentes d’une troisième classe, cela augmente la probabilité que les modifications apportées à l’une des deux premières classes affectent l’autre.

Supposons que nous ayons trois classes : Red, Green, et Blue.

Red et Green les deux dépendent Blue, mais chacun dépend d'une méthode différente.Cela signifie que Red dépend d'une méthode de Blue mais n'utilise pas l'autre méthode.De même, Green dépend de Blue, mais n'utilise qu'une seule méthode, pas l'autre.

La violation du principe réside dans Red et Green parce que chacun dépend d'une classe - Blue - mais n'a pas utiliser au moins une de ses méthodes.

Quel problème cela peut-il créer ?

• J'ai besoin de changer Red, et je change aussi Blue pour répondre aux besoins de Red.
• Je n'ai pas changé la méthode spécifique dans Blue que Green cela dépend, mais néanmoins, Green dépend de Blue et j'ai changé Blue, ce qui pourrait encore avoir un impact Green.
• Par conséquent, mes modifications à Red ont le potentiel d'avoir un impact Blue parce qu'ils m'ont amené à changer de classe dont dépendent tous les deux.

C'est la «force en arrière». Nous changeons parfois une classe en raison des besoins de ses clients.Si cette classe a différents clients qui l’utilisent à des fins différentes, nous risquons d’avoir un impact sur eux.

Comme indiqué, la définition simple du principe de ségrégation d'interface est la suivante :

aucun client ne devrait être obligé de dépendre de méthodes qu’il n’utilise pas.

Entre cela et le point ci-dessus tiré de l'article de Robert Martin, il est évident que de nombreuses explications du FAI parlent en fait d'autres principes.

• Les classes ou interfaces comportant de nombreuses méthodes ne sont pas souhaitables, mais pas spécifiquement à cause du FAI.Ils pourraient violer la responsabilité unique.Mais la violation du FAI ne concerne pas la grande interface ou la grande classe, mais les classes qui dépend de sur la grande interface s'ils n'utilisent pas toutes ses méthodes.S’ils utilisent toutes les méthodes, cela semble toujours compliqué, mais cela n’a rien à voir avec le FAI.
• Les classes qui implémentent une interface mais lèvent des exceptions pour certaines méthodes sont mauvaises, mais ce n'est pas non plus le FAI.Le FAI concerne les classes qui dépendre sur les interfaces, pas sur les classes qui mettre en œuvre interfaces.

Si nous recherchons la « ségrégation des interfaces » sur Google, la plupart des meilleurs résultats qui incluent des exemples de code démontrent des classes qui ne pas mettre pleinement en œuvre interfaces, ce qui n'est pas le but du FAI.Certains reformulent même le principe :

Le principe de ségrégation des interfaces stipule que les clients ne doivent pas être obligés d'implémenter des interfaces qu'ils n'utilisent pas.

... mais c'est pas le principe.Le document de définition mentionne ces préoccupations comme un effet secondaire de la violation du FAI, mais indique qu'il s'agit de violations de la substitution Liskov.

De plus, chaque fois qu'une nouvelle interface est ajoutée à la classe de base, cette interface doit être implémentée (ou autorisée à par défaut) dans les classes dérivées.En effet, une pratique associée consiste à ajouter ces interfaces à la classe de base en tant que fonctions virtuelles nulles plutôt que fonctions virtuelles pures ;spécifiquement pour que les classes dérivées ne soient pas surchargées par la nécessité de les implémenter.Comme nous l'avons appris dans le deuxième article de cette chronique, une telle pratique viole le principe de substitution de Liskov (LSP), entraînant des problèmes de maintenance et de réutilisation.

De plus, dire qu'un client ne doit pas implémenter des méthodes qu'il n'utilise pas n'a même pas de sens.Le clients d'une interface n'implémente pas ses méthodes.

Je ne veux pas citer pompeusement le document comme s’il s’agissait d’écritures saintes ou quelque chose du genre.Mais si nous devons utiliser le nom du principe décrit dans l'article (le nom de l'article lui-même), nous devrions également considérer la définition et l'explication réelles contenues dans cet article.