Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

WPF / Silverlight : MVVM est-elle une vraie pattern ?

[new:30/08/2011]Il y a déjà quelques temps j’ouvrais le débat “Faut-il bruler MVVM ?” où j’expliquais qu’il y a peut-être matière à réflexion autour d’une réforme de cette pattern qui ne tient pas toutes ses promesses. Aujourd’hui je vais un cran plus loin en affirmant que MVVM n’est pas une pattern.

Masochisme ?

D’abord, vous risquez de penser que je suis masochiste. C’est vrai, pourquoi m’acharner à utiliser une pattern que je trouve si imparfaite ? Pourquoi ne pas lâcher l’affaire et passer à autre chose ? Il y a tellement de pattern du même type...

Alors je dois réaffirmer que MVVM contient de nombreuses bonnes idées qui sont des avancées difficiles à renier, que MVVM est récente et conçue dans l’esprit XAML et que revenir en arrière en l’abandonnant totalement serait idiot.

Quant à utiliser “autre chose”, je ne connais rien du même type qui soit parfait. MVP (créée en 96 par Mike Potel pour C++ et IBM Java), VP et toutes leurs cousines reposent sur des principes proches mais pour d’anciens systèmes et, à l’usage, s’avèrent aussi poser des problèmes. Je ne parle même pas de patterns comme MVC (issue de Smalltak dans les années 70 !) qui finissent divisées en sous-branches incompréhensibles (MVC a été “revue” par Martin Fowler et dérivée en “Supervising Controler” et en “Passive View”, patterns bien difficiles à différencier).

Dans le précédent billet que je cite plus haut, je souhaitais ouvrir un débat, une discussion large sur les faiblesses de MVVM dans le but d’initier une “réforme”, une évolution de la pattern. C’est toujours dans ce même esprit que je m’exprime aujourd’hui.

MVVM est “la bonne idée”, en tout cas le bon noyau fondateur, moderne, mais il lui manque des choses.

Qu’est-ce qu’une pattern ?

Une “design pattern” ou “patron de conception” est un concept de génie logiciel hérité de l’architecture. C’est en effet un architecte viennois (mais ayant vécu en Angleterre ce qu’on oublie souvent), Christopher Alexander qui dans les années 70 eut l’idée d’écrire un livre qui se composait de “recettes” applicables en architecture. Chaque pattern étant présentée sous une forme bien précise : son nom, le problème à traiter, la solution détaillée (éléments en jeu, leurs relations et responsabilités) et les conséquences... De la poigné de porte à une ville entière, Alexander définissait ainsi un catalogue de solution éprouvées (“A Pattern Language : Towns, Buildings, Construction”).

En informatique l’idée sera reprise en 1995 par le célèbre “Gang of Four” ou GoF (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) dans leur livre “Design Patterns – Elements of Reusable Object-Oriented Software”.

Une design pattern est un formalisme. On trouve d’autres segmentations que celles d’Alexander comme “Intention, Motivation, Solution, Conséquences”. Mais l’idée reste la même, le formalisme de base reste cohérent.

Chaque “design pattern” décrit ainsi un problème spécifique mais qui se rencontre couramment dans l’écriture d’un logiciel. Après avoir décrit le problème et son contexte, les auteurs décrivent une solution fiable aux conséquences connues (par exemple sur la vitesse d’exécution, la consommation mémoire). Le but étant de décrire chaque problème et sa solution de telle façon “que l’on puisse réutilisation cette solution des millions de fois, sans jamais le faire deux fois de la même manière”.

Les design patterns sont des condensés de savoir et d’expérience. Le GoF était constitué d’experts, des gens qui écrivaient de vrais logiciels et qui avaient atteint une maitrise certaine de leur art. Ce n’était pas des théoriciens fous, des méthodologistes universitaires enfermés dans leur tour d’ivoire.

Les designs patterns sont le fruit d’une réflexion poussée autour d’une expérience. Il ne s’agit pas surtout de “ballons d’essai théorique” lancés en l’air pour '”voir ce que cela va donner” ! Au lieu de partir d’une théorie, d’une méthode de chercheur et d’essayer d’en trouver des applications pratiques, avec les design patterns ont part de l’expérience, enrichie par plusieurs vécus différents, et on tente de formaliser ce savoir accumulé. C’est totalement différent. Dans un cas on est dans l’essayisme pur et dangereux, dans le second on avance en terre connue et balisée par la pattern.

Je dirais même que les design pattern, que ce sont ensuite réappropriés les théoriciens et autres méthodologistes, sont en quelque sorte la revanche des ingénieurs sur ces derniers. Les design pattern prouvent que dans notre métier, comme en architecture, il est bien préférable, pour créer de bons logiciels, de formaliser son expérience que de vouloir imposer des théories non éprouvées par les faits issue de chercheurs qui jamais n’ont écrits le moindre logiciel...

Donc voici ce qu’est une design pattern : un sirop, un extrait, un élixir d’expérience formalisée aux conséquences mesurées, assumées, et commentées.

Les conséquences font la pattern

En fait, on pourrait en arriver à définir les design patterns par la fin : c’est bien plus la mise en évidence claire des conséquences positives et négatives de leur application qui en fait des patterns réutilisables que l’exposé de la solution au problème !

Des solutions aux problèmes, interrogez 100 développeurs et vous obtiendrez 100 réponses différences.

Nous ne sommes pas à la recherche de solutions.

Nous sommes à la recherche d’expérience !

Et ce qui caractérise une design pattern est bien la partie “conséquence” de sa présentation. C’est ce qui prouve qu’elle est issue de l’expérience et qu’on peut prévoir à quoi s’attendre en l’appliquant.

Sans cela, une design pattern n’est qu’une solution parmi des centaines. Pire, qu’une “bonne idée” qu’il reste à tester avant d’en faire une pattern, donc dangereuse à utiliser...

C’est l’expérience véhiculée par les conséquences clairement énoncées qui font toute la valeur d’une design pattern.

Bien entendu, l’élégance de la solution proposée compte aussi. Mais sans le retour d’expérience qui s’exprime par la connaissance des conséquence de son utilisation, cela resterait qu’une solution de plus. Des solutions élégantes il est toujours possible d’en trouver plusieurs pour un même problème. Mais qui soient validées par l’expérience de leur mise en pratique, il y en a moins, et ce sont des design patterns dès que tout cela est formalisé sérieusement.

MVVM peut-elle être considérée comme une design pattern ?

Non.

Elle ne se présent pas comme une design pattern du GoF par exemple. Et notamment il lui manque l’essentiel : les conséquences connues et prévisibles de son application.

MVVM est juste une entrée de blog... Une bonne idée présentée par John Gossman le 8 octobre 2005 dans l’un de ses billet intitulé “Tales Form The Smart Client”.

MVVM ouvre des voies, assène des lois, fait la publicité de tout ce qu’elle apporte de bon, mais jamais MVVM n’explique les conséquences de son utilisation. Jamais elle ne permet d’avoir cette assurance qu’une vraie design pattern apporte.

MVVM est une bonne idée lancée en l’air, mais elle n’est pas présentée comme doit l’être une design pattern, elle n’en suit pas le formalisme et elle ne se base pas sur une longue expérience qu’on tente de formaliser. Elle née presque en même temps que les techniques qu’elle utilise, comme une guideline. Mais pas comme une pattern riche d’un retour d’expérience.

De fait, MVVM c’est juste une “bonne idée” qui est lancée en l’air. Chacun essayant de l’appliquer à sa façon. Avec plus ou moins de bonheur.

Prism, Caliburn, MVVM Light, Jounce, et bien d’autres toolkits ou frameworks tournent plus ou moins directement autour de l’idée de MVVM. Aucun ne règle tous les problèmes et souvent en pose de nouveaux qui restent sans solution.

Appliquer MVVM oblige à choisir un toolkit, et avec lui ses inévitables faiblesses. Beaucoup de ces toolkits sont d’ailleurs l’œuvre d’un seul homme (MVVM Light, Jounce, Caliburn...) qui, aussi compétent soit-il, fabrique son toolkit personnel en fonction de sa propre expérience puis tente, en fonction des retours (les siens et de ses utilisateurs) de combler les manques. C’est ainsi que le concepteur de Caliburn a décidé de tout reprendre à zéro et de concevoir Caliburn.Micro, non pas comme une version minimaliste mais bien en remplacement de Caliburn. On avance par petit sauts, on bricole chacun dans son coin, on recommence. C’est beau, cela s’appelle s’expérience et c’est justement ce qui manque à MVVM pour être une vraie pattern...

Mais quand je prend une design pattern du GoF, je n’ai pas tous ces aléas... J’ai du solide, du prévisible, toujours valable presque 20 ans après la sortie de leur livre ! C’est ça une design pattern : quelque chose de solide et de fixe, un moule sur lequel on peut compter, tout en ayant la liberté de réaliser autant de versions différentes selon les besoins. Mais jamais on ne remet en question le moule lui-même, la design pattern.

Je ne voudrais pas donner l’impression de “sacraliser” les design patterns du GoF. Rien n’est sacré, pas même le sacré. Je suis un libre penseur et aucune loi, ni divine ni humaine ne s’impose à moi sans que je m’octroie le droit légitime et absolu de l’examiner, de la soupeser, d’en vérifier la validité.

Les design patterns du GoF ne sont donc pas sacrées. Elles sont juste bien faites et je peux compter sur elles !

MVVM n’est pas de cette nature.

MVVM est juste une “bonne idée”, ou plutôt une liste de “bonnes idées”. Une direction intéressante à suivre, une réflexion empreinte de bon sens. Mais comme toutes les “bonnes idées”, il ne s’agit pas d’un “package complet” utilisable “tel quel”, juste un guide qui doit forcer à raisonner, à s’interroger.

MVVM est “l’idée d’une pattern” qu’il reste à créer.

Quelles conséquences à ce changement de statut ?

En remettant MVVM à sa place, en la délogeant du piédestal du statut de design pattern, on ne tue pas les bonnes idées qu’elle véhicule. Dans ce billet-ci non plus je ne brulerais pas MVVM !

En revanche je la remets à sa place : de bonnes idées qui nécessitent encore beaucoup de travail et d’expérience avant d’atteindre le niveau de ce que doit être une vraie design pattern.

C’est une invitation au travail, à la réflexion. Ce n’est pas un discours nihiliste, d’aucune manière.

MVVM mérite notre attention. Mais on ne peut la considérer comme une design pattern “finie”. Juste “l’idée de ce que pourrait être une pattern de ce type”.

Elle pose trop de questions sans réponses, elle laisse le champ libre à trop d’interprétations personnelles, à trop de frameworks ou de toolkits radicalement différents qui chacun ne répond que partiellement aux attentes.

Prenons un simple exemple : MVVM a été pensé par un fondateur de WPF. MVVM fait donc usage du data binding et de tout ce qui caractérisait à l’époque WPF. Null doute que si MVVM avait été énoncé hier, elle prendrait en compte la blendabilité. Sur l’ensemble des toolkits cités dans ce billet, seul MVVM Light prend ce point essentiel en compte (avec Jounce mais d’une autre façon).

Mais pour y arriver MVVM Light utilise un locator avec des propriétés statiques. Impossible d’utiliser MVVM Light et sa blendabilité avec MEF par exemple...

Est-ce la faute de MVVM Light de ne pas offrir de solution à ce problème, est-ce la faute de MEF de ne rien prévoir pour la blendabilité ? Ou bien est-ce la faute à la “pattern” MVVM ne n’être pas “finie”, pas complète, de manquer de recul, de n’être pas capable de suivre les évolutions du monde qui l’a vu naitre ?

Si on considère que MVVM n’est qu’une bonne idée, qu’une voie à suivre et à étudier, alors on comprends mieux la situation : chacun tâtonne, essaye de donner “son” interprétation de ce qu’il comprend de l’essence de MVVM, mettant l’accent sur ce qui le gêne au quotidien, ignorant superbement les autres problèmes posés par l’application de cette “pattern”.

Il reste beaucoup de travail avant de faire de MVMV une design pattern.

Les conséquences de cet état fait sont évidentes : Appliquer MVVM comme une pattern est une erreur. Croire que tel ou tel “écart” en “viole” les lois est stupide car on ne viole pas une “bonne idée”, on ne viole qu’une pattern. Une bonne idée, on “l’adapte”, grâce à l’expérience. Cela fait une grande nuance.

Et alors ?

Bonne question... Je n’ai pas de solution à vous offrir, et ce n’était pas mon propos. Je voulais seulement rappeler que MVVM n’est que le début du chemin qui mènera à une design pattern, mais qu’en l’état ce n’en est pas une. Avec toutes les conséquences que cela entraine.

  • La fin des discours parfois extrémistes sur tel ou tel “viol” de la pattern.
  • La fin du rêve qu’un '”absolu” serait atteint en appliquant la “pattern”.
  • La fin de l’illusion qu’appliquer MVVM répond à tous les problèmes qu’elle soulève.
  • Le début d’une nouvelle histoire qui reste à écrire.
  • Le début d’une nouvelle impulsion, pour se mettre au travail et trouver comment faire de cette bonne idée une vraie pattern...

Conclusion

Dans notre métier secoué régulièrement par les modes et les sigles étranges qui font passer pour des idiots ceux qui n’en connaissent pas la signification, MVVM a su créer son buzz. On pourrait dire qu’il n’y a pas de fumée sans feu. C’est souvent vrai (pas toujours), et si MVVM connait un certain succès c’est bien qu’elle véhicule de bonnes idées, séduisantes.

Mais MVVM ne serait rien sans les toolkits ou frameworks qui en offre une vision personnelle. C’est grâce à ces outils que MVVM gagne en expérience ce qui lui permettra, un jour peut-être, d’atteindre le statut de “design pattern”.

Il est ainsi hors de question de jeter la pierre à tel ou tel autre framework. Il est tout autant hors de propos de les renier et d’oublier les voies que tracent MVVM.

Il faut continuer à mettre œuvre MVVM, il faut que chacun exploite plusieurs toolkits et frameworks pour en comprendre les forces et les faiblesses.

Il n’y a que comme cela, par l’accumulation de l’expérience, qu’un jour, l’un d’entre nous sera capable de formaliser réellement MVVM, d’en faire une vraie design pattern aux conséquences maitrisées et sur laquelle pourront être bâtis des frameworks solides et non pas parcellaires.

Rendons une fois encore hommage à ceux qui produisent des frameworks ou des toolkits MVVM, ils font avancer les choses. Rendons un hommage tout aussi appuyé à ceux qui ont le courage de s’en servir pour créer de vraies applications qui dépassent le stade de la démonstration. Leur prise de risque est énorme et leur expérience accumulée est notre espoir de fonder une vraie pattern sur MVVM. Rendons peut-être aussi, et très humblement, un hommage à ceux qui réfléchissent à MVVM et qui prennent parfois beaucoup de temps à l’expliquer à la communauté pour faire avancer les choses...

D’ailleurs, après le gros article sur MEF (qui sera publié d’ici quelques jours), je vais m’attaquer à une présentation en détail de Jounce que je trouve très séduisant.

Autant de raisons de....

Stay Tuned !

blog comments powered by Disqus