C'est avoir un code où différent modules se concentre sur une tâche spécifique qu'il font bien, les tâches se composent ensuite naturellement en des choses plus complexes.
Comme je l'entends, le terme orthogonalité vient effectivement de l'espace de vecteurs. Quand tu décris la position d'un point dans l'espace, tu utilises un système de coordonnées composé de vecteurs. Tu peux très bien le faire avec des vecteurs non orthogonaux (mais qui génèrent bien tout l'espace), mais chaque point a alors plusieurs coordonnées possibles. Si tu choisis des vecteurs orthogonaux, tu as un et un seul vecteur coordonnées pour chaque point. De manière intuitive, les vecteurs de ton repère ne répètent pas une information présent dans un autre (la projection d'un des vecteurs sur les autres est nulle).
Dans le logiciel, tu essaye d'avoir des fonctionnalités simples et complètes mais qui ne répètent pas ce que font les autres (ici : sélection, édition etc..., mais pas remplacement car c'est une sélection / édition) mais se composent ensemble pour permettre un vaste ensemble d'interaction (ton espace).
L'avantage c’est que tu génère moins d'incohérence et facilite la maintenabilité (une évolution n'est pas à reporter à plusieurs endroit à la fois, tu peux éventuellement faire évoluer chaque fonctionnalité indépendamment, mais en augmentant toujours les interactions possibles, chaque fonctionnalité a une cohérence interne bien focalisée qui permet de plus facilement dérouler la logique). Le désavantage c'est que n'ayant pas de définition formelle de l'orthogonalité, c'est un peu au nez que tu le définis (où plutôt à l'expérience). C'est également un type de design qui demande plus une vision d'ensemble pour résoudre les cas d'usages concrets.
Bien sur ce n'est pas une définition de logique formelle mais uniquement analogique (mais ça a de la valeur en sois, et tu peux le mesurer en pratique).
[^] # Re: Design orthogonal
Posté par Alex G. . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 5.
Ce n'est pas pipo et tout à fait utile.
C'est avoir un code où différent modules se concentre sur une tâche spécifique qu'il font bien, les tâches se composent ensuite naturellement en des choses plus complexes.
Comme je l'entends, le terme orthogonalité vient effectivement de l'espace de vecteurs. Quand tu décris la position d'un point dans l'espace, tu utilises un système de coordonnées composé de vecteurs. Tu peux très bien le faire avec des vecteurs non orthogonaux (mais qui génèrent bien tout l'espace), mais chaque point a alors plusieurs coordonnées possibles. Si tu choisis des vecteurs orthogonaux, tu as un et un seul vecteur coordonnées pour chaque point. De manière intuitive, les vecteurs de ton repère ne répètent pas une information présent dans un autre (la projection d'un des vecteurs sur les autres est nulle).
Dans le logiciel, tu essaye d'avoir des fonctionnalités simples et complètes mais qui ne répètent pas ce que font les autres (ici : sélection, édition etc..., mais pas remplacement car c'est une sélection / édition) mais se composent ensemble pour permettre un vaste ensemble d'interaction (ton espace).
L'avantage c’est que tu génère moins d'incohérence et facilite la maintenabilité (une évolution n'est pas à reporter à plusieurs endroit à la fois, tu peux éventuellement faire évoluer chaque fonctionnalité indépendamment, mais en augmentant toujours les interactions possibles, chaque fonctionnalité a une cohérence interne bien focalisée qui permet de plus facilement dérouler la logique). Le désavantage c'est que n'ayant pas de définition formelle de l'orthogonalité, c'est un peu au nez que tu le définis (où plutôt à l'expérience). C'est également un type de design qui demande plus une vision d'ensemble pour résoudre les cas d'usages concrets.
Bien sur ce n'est pas une définition de logique formelle mais uniquement analogique (mais ça a de la valeur en sois, et tu peux le mesurer en pratique).