Orthogonalité en génie logiciel

Orthogonalité

En génie logiciel, un système est considéré comme orthogonal si la modification de l'un de ses composants modifie l'état de ce composant uniquement.

Par exemple, considérons un programme avec trois variables: a, b et c. Changer la valeur de a ne devrait pas changer la valeur de b ou de c, à condition qu'ils soient indépendants.

Cette propriété est particulièrement critique dans le débogage d'un programme car on s'appuie sur la réduction du nombre de parties mobiles d'un programme pour identifier la cause première du problème.

Voir la citation suivante de «L'art de la programmation UNIX» d'Eric S. Raymond:

L'orthogonalité est l'une des propriétés les plus importantes qui peuvent aider à rendre compact même les conceptions complexes. Dans une conception purement orthogonale, les opérations n'ont pas d'effets secondaires; chaque action (qu'il s'agisse d'un appel d'API, d'un appel de macro ou d'une opération de langage) ne change qu'une seule chose sans affecter les autres. Il existe une et une seule façon de modifier chaque propriété du système que vous contrôlez.

L'orthogonalité est un principe de conception logicielle permettant d'écrire des composants de manière à ce que la modification d'un composant n'affecte pas les autres composants. C'est la combinaison de deux autres principes, à savoir une forte cohésion et un couplage lâche.

C'est en fait un terme emprunté aux mathématiques. Par exemple, deux lignes sont orthogonales si elles sont perpendiculaires. Dans la conception de logiciels, deux composants sont orthogonaux si un changement dans l'un n'affecte pas l'autre.

L'application de ce concept à des classes ou à d'autres sections de code entraîne moins de couplage. Pour être orthogonales, deux classes ne peuvent dépendre l'une de l'autre implémentation. Ils ne peuvent pas non plus partager des données mondiales. La modification des éléments internes d'une classe n'affecte pas l'autre classe. Les composants doivent être indépendants et n'avoir qu'une seule responsabilité.

Considérez une méthode qui lit une liste de nombres à partir d'un fichier et les renvoie dans l'ordre trié. Maintenant, les exigences changent et les chiffres sont dans une base de données. La modification de cette méthode pour accéder à la base de données entraînerait la modification du code client. S'il s'agissait de deux méthodes différentes, une nouvelle source n'affecterait pas la méthode de tri. Seul le code client devrait connaître la source des numéros.

Cohésion forte

À l'intérieur d'un composant logiciel, le code doit être fortement connecté. Ceci indique que le code est correctement divisé.

Si un composant a deux pièces ou plus relativement déconnectées, cela peut indiquer que ces pièces doivent être dans un composant différent, ou seules.

Couplage lâche

Entre les composants logiciels, il devrait y avoir peu de connexions. Si deux composants sont fortement couplés, cela peut indiquer qu'ils doivent être un composant ou qu'ils doivent être divisés différemment en plusieurs composants.