Principe de ségrégation des interfaces

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.

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.

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.