— PNK

Nous autres, informaticiens, aimons généraliser. Abstraire. C’est un réflexe métier que l’on ne prend plus la peine de justifier.

On généralise car cela simplifie la vie. Des choses aux propriétés communes s’utilisent ou se fabriquent probablement, au moins en partie, de la même façon. On n’a donc à les penser qu’une fois.

C’est ainsi qu’hier, en utilisant la dernière version d’Adobe Reader, j’ai été assailli par l’intuition d’un problème connu. L’impression de toucher à quelque chose d’intéressant, sans savoir quoi.

Concrètement, une bulle d’aide masquait partiellement mon document.

Au premier degré, j’étais simplement agacé qu’une information totalement inutile (une aide sur quelque chose que je ne voulais pas faire) masque ce qui m’était utile (mon document).

Et ça continuait à me titiller. Plus que le simple agacement de devoir cliquer pour faire disparaître la bulle. Il y avait quelque chose derrière ça. Sans doute trouvais-je un peu gros qu’un logiciel dont la fonction était d’afficher un document commence par faire obstruction à la lecture de ce document.

Et pourquoi avait-il besoin d’afficher cette bulle d’aide, d’abord ? De quelle aide pouvais-je avoir besoin pour utiliser un logiciel à la définition si simple, l’affichage de document ? Un éditeur comme Adobe était-il incapable de rendre un afficheur de document utilisable sans aide ? Non, ce n’était pas cela : mon document était affiché et lisible, à l’obstruction de l’aide près. Aide qui concernait d’obscures fonctions de conversion, de commentaire, etc.

Ce qu’Adobe n’avait pas su faire, c’était de ne pas intégrer ces fonctions avancées dans un simple lecteur (Adobe Reader). La définition du logiciel n’étant plus respectée, les propriétés associées, comme la simplicité, étaient en train de disparaître. Ce qui me gênait, c’était l’aide d’un autre logiciel. Un qui m’indifférait et qui s’était glissé dans le visualiseur.

C’est là, précisément, que le lien s’est établi. Ce logiciel ne respectait pas les principes de conception objet, non pas dans sa conception logicielle (dont je n’ai pas la moindre idée) mais en tant qu’objet du monde réel.

Pour les profanes, cela mérite une parenthèse. Les principes de conception objet sont un ensemble de règles qu’il est hautement recommandé de suivre quand on met au point l’organisation interne d’un logiciel. Ils sont bien trop vastes pour être exposés ici mais le net abonde de ressources à ce sujet. Je vais donc supposer, par la suite, que vous êtes familiers avec des choses comme l’inversion des dépendances, le principe de substitution de Liskov, etc. Si ce n’est pas le cas, vous n’avez plus qu’à vous venger en me déversant à la tronche le jargon de votre métier.

Et telle fut ma révélation : Adobe Reader ne respecte pas le principe de séparation des interfaces (ISP). En effet, en tant qu’utilisateur, je suis perturbé, pendant une tâche de lecture, par l’intrusion d’un élément d’interaction totalement étranger à cette tâche.

Ce principe concerne normalement une interface de programmation et est formulé ainsi par Philippe Vialatte sur developpez.com : « Les clients d’une entité logicielle ne doivent pas avoir à dépendre d’une interface qu’ils n’utilisent pas. » Pour une interface graphique, il n’y a qu’à remplacer clients par utilisateurs et la définition est directement applicable. Exemple de conséquence concrète : les outils concernant des fonctions disjointes ne doivent pas empiéter les uns sur les autres.

Adobe Reader ne respecte pas non plus un principe plus radical : le principe de responsabilité unique (SRP). En effet, il a une responsabilité d’affichage (c’est même sa définition, d’où son nom Adobe Reader) mais il a aussi quelques fonctions d’édition, de travail collaboratif, etc. L’application stricte du SRP voudrait d’Adobe créât deux logiciels, un pour l’affichage, un pour le travail plus avancé. Les principes n’étant que des lignes de conduite, il convient de les appliquer raisonnablement, et il semble ici raisonnable qu’Adobe ait groupé des fonctions quand même très connexes. On retrouve exactement les mêmes problématiques qu’en conception objet, où la simplicité d’utilisation s’oppose souvent à la « pureté » de l’interface. On peut même dire qu’Adobe a mis en oeuvre le design pattern « façade » pour simplifier l’accès à un ensemble de fonctions.

Tout ça ne se goupille pas mal du tout. Les principes de conception logicielle semblent trouver leurs équivalents hors des langages orientés objet. Par exemple, on vient de les appliquer au langage graphique interactif par lequel le logiciel s’adresse à l’humain. Ce n’est pas si étonnant car ces principes sont exprimés en termes d’interactions entre clients (utilisateurs) et fournisseurs (fabricants) à travers un langage commun. Ou, ce qui revient un peu au même, car les objets logiciels ne portent pas ce nom au hasard : ils partagent bien des propriétés des objets réels.

On a vu l’application (ou le défaut d’application) de deux principes de conception (ISP et SRP) et d’un design pattern (façade) à un objet de notre quotidien (le logiciel Adobe Reader).

Il est tentant de se demander si les autres principes, design patterns, etc., trouvent leurs équivalents en conception d’objets du quotidien. Après tout, les design patterns ont bien été inspirés par les patterns d’architecture, ces agencements « pré-pensés » qu’on retrouve dans les bâtiments réels.

Le principe de substitution de Liskov peut-il être mis en oeuvre en termes concrets ? Peut-on utiliser le principe d’inversion des dépendances pour mettre au point des objets plus faciles d’utilisation ? Qu’est-ce qu’une interface abstraite quand on essaie de la sortir du contexte logiciel ?

Mon intuition d’une généralisation tient-elle ?

Je tenterai d’y répondre dans un futur billet.