Principe de ségrégation des interfaces
En programmation orientée objet, le principe de ségrégation des interfaces (en anglais : Interface Segregation Principle ou ISP) stipule qu'aucun client ne devrait dépendre de méthodes qu'il n'utilise pas[1]. Il faut donc diviser les interfaces volumineuses en plus petites plus spécifiques, de sorte que les clients n'ont accès qu'aux méthodes intéressantes pour eux. Ces interfaces rétrécies sont également appelées interfaces de rôle[2]. Tout ceci est destiné à maintenir un système à couplage faible, donc plus facile à refactoriser.
Le principe de ségrégation des interfaces correspond au « I » de l'acronyme SOLID. Il est comparable à la cohésion des principes GRASP[3].
Importance dans la conception orientée objet modifier
Dans une conception orientée objet, les interfaces fournissent des couches d'abstraction qui facilitent l'explication du code, et créent une barrière empêchant le couplage à des dépendances.
Selon de nombreux experts en logiciel qui ont signé le Software craftsmanship, écrire un code compréhensible est presque aussi important qu'un code qui marche[4]. Les interfaces décrivant les intentions du logiciel sont donc souvent une bonne idée.
Un système peut devenir tellement couplé à de multiples niveaux qu'il n'est plus possible de faire un changement dans un seul endroit, sans recourir à de nombreux autres. Une interface ou une classe abstraite peut éviter cet effet secondaire.
Historique modifier
Le principe de ségrégation des interfaces a d'abord été utilisé et formulé en 2002 par Robert C. Martin, consultant pour Xerox. L'entreprise avait créé un nouveau système d'imprimante qui pouvait effectuer une variété de tâches telles que l'agrafage et la télécopie. Le logiciel de ce système a été créé en approche ascendante. Puis le logiciel a grandi, imposant des modifications de plus en plus difficiles, de sorte que même le plus petit changement nécessitait un cycle de redéploiement d'une heure, ce qui rendait son développement presque impossible.
Le problème de conception était qu'une seule classe Job était utilisée par presque toutes les tâches par exemple à chaque fois qu'une tâche d'impression ou un agrafage travail devait être effectué. Cela a entraîné un "gras" de la classe, avec une multitude de méthodes spécifiques pour toutes sortes de clients différents. En raison de cette conception, un job d’agrafage chargeait toutes les méthodes de la tâche d'impression, même les inutiles.
La solution proposée par Martin utilisait ce que l'on appelle aujourd'hui le principe de ségrégation des interfaces. Appliqué au logiciel Xerox, une couche d'interface entre la classe et ses clients a été ajoutée à l'aide de l'inversion de dépendance. Au lieu d'avoir une grosse classe Job, une interface d’agrafage et une interface d'impression ont été créées, utilisant seulement certaines méthodes de la classe Job.
Violation typique modifier
Une violation typique du principe de ségrégation d'interface est donnée dans l'Agile Software Development: Principles, Patterns, and Practices, dans ATM Transaction example, et dans un article écrit par Robert C. Martin dédié au principe[5]. Cet exemple décrit l'interface utilisateur d'un distributeur de billets, qui gère toutes les demandes telles qu'une demande de dépôt ou de retrait, et la façon dont cette interface doit être divisée en des interfaces plus spécifiques.
Références modifier
- Martin, Robert (2002). Agile Software Development: Principles, Patterns, and Practices. Pearson Education.
- « bliki: RoleInterface »
- David Hayden, Interface-Segregation Principle (ISP) - Principles of Object-Oriented Class Design
- « Manifesto for Software Craftsmanship », sur manifesto.softwarecraftsmanship.org
- Robert C. Martin,The Interface Segregation Principle, C++ Report, June 1996
