| « Generics in .NET 2.0 make "polymorphic" delegates real ! | Looking for a multi-purpose text editor ? » |
La couche de présentation est-elle la moins stable ? (II)
Sami a ouvert un débat très intéressant.
Je souhaite l'élargir, en rebondissant sur ce que dit Sami : "Factoriser du code lorsqu’on gère 40 évènements dans un écran contenant 50 champs et autant de contrôles de surface relève du défi" et en posant la question suivante : si la couche de présentation est effectivement la moins stable, cela ne vient-il pas de ce sacro-saint modèle de programmation évènementiel ?
Je n'ai pas la réponse à cette question mais des chercheurs ont déjà fait le constat que ce modèle évènementiel souffrait de nombreux défauts.
Témoin les travaux du Professeur Petitpierre de l'Ecole Polytechnique Fédérale de Lausanne, comme "Synchronous Java".
De quoi s'agit-il au juste ? D'une amélioration syntactique significative au langage Java définissant directement dans le langage :
- le concept d'objet actif et de méthode bloquante. Lorsqu'on appelle une méthode sur une instance d'une classe active (c'est-à-dire un objet actif), l'appel est bloqué tant que l'object actif (qui tourne par définition dans son propre thread) n'a pas accepté l'appel
- la notion de choix entre appels. SJava permet de lancer parallèlement plusieurs invocations de méthodes sur objects actifs. Le premier appel qui est accepté sera exécuté, les autres abandonnés.
- et bien d'autres choses passionnantes
Quel rapport avec la couche de présentation, me direz vous ? Eh bien le modèle évènementiel est justement lié au fait que dans une interface utilisateur, on ne sait pas à l'avance où va cliquer l'uitlisateur. Plusieurs contrôles peuvent être activés en même temps, offrant leurs services à l'utilisateur. Il se peut du reste qu'un évènement applicatif interne (notification, timeout) se produise avant même qu'un évènement utilisateur se produise.
Le concept de choix introduit par SJava permet de s'affranchir de 2 problèmes identifiés par les auteurs de ces travaux :
- les event listeners favorisent un style de programmation aussi peu lisible et condamnable que les GOTOs
- le diagramme d'état d'une application n'est pas immédiatement visible à celui qui lit le code des event handlers (en habitué des code-behinds, même réduits à leur plus simple expression, je souscris à ce point de vue)
Et j'arrête la paraphrase ici, ce lien vous dira tout ou presque sur le sujet.
En bref, pour revenir à la question initialement posée : la couche de présentation n'est-elle pas la moins stable parce que nous ne disposons pas de l'outil/syntaxe approprié pour représenter de manière informatique le séquencement des opérations effectuées par un utilisateur ?
Ce que j'aimerais, et ce qui arrivera peut-être un jour via une technologie adaptée, c'est un mapping 1-1 entre ce que l'on écrit typiquement dans un use case specification (l'utilisateur fait ceci, le système répond cela, l'utilisateur fait cela, le système répond autre chose), c'est-à-dire une représentation séquentielle des choses, et le code. Mais l'évènementiel empèche pour l'instant cette lisibilité.
3 commentaires
Ce propos est irréaliste et démesuré. Pour en arriver là, il doit avoir un problème de Design et d'Ergonomie.
Si l'on se contente de donner à chaque chose sa responsabilité, on arrive à éliminer certaines tâches répétitives.
Comme on parle de "Evenementiel", je ne comprends pas pourquoi on n'en parle pas de celui de ASP.NET ?
ASP.NET propose de façon très élégante la centralisation des eventements utilisateurs via des noms de commandes (CommandName). Et j'en parle même pas des Evenements qui sont utilisés au niveau des controls tels que DataList, DataGrid, ....
Pour répondre à la question : Non si les développeurs qui la développent se prennent comme des pieds et non aucune capitalisation de codes.
Il me semble important de ne pas "perdre" de temps avec l'interface graphique car on est vite emporté dans des excès à l'utilité plus que discutable. Il faut se concentrer sur les pbs de fond qui peuvent, eux, entraîner un projet dans le gouffre. De toute façon, qd le client découvre l'interface graphique, il veut tjrs des changements, rendant la couche de présentation instable.
ps : j'ajouterai que si l'architecture de l'application est bonne, l'interface graphique ne doit contenir rien de bien intéressant d'un point de vue fonctionnel. Donc sa valeur est somme toute réduite.
ps : j'ai peut-être présenté la relation avec le client de façon un peu noire mais sauf cas exceptionnel, le client se focalise de façon naturelle (et logique) sur l'interface graphique ce qui permet de vendre des applications moyennes mais belles. Le fond et la forme ...
Il y a peut-être un truc qui m'échappe, mais je ne vois pas l'intérêt de revenir à une boucle événementielle à la MFC.
C'est en fait la première fois que j'entends se plaindre du modèle événementiel en ces termes.
Si on regarde l'évolution des langages, on y verrait plutôt une distantiation entre la syntaxe et le flot d'exécution (par exemple avec le yield de C#), et c'est une bonne chose: tous les processus ne sont pas linéaires, loin de là.
Flux de commentaires pour cet article