Je pense que l'article est un peu démodé parce que, comme je l'ai lu, ce n'est pas vraiment une idée peu orthodoxe ou nouvelle. Cette idée est présentée comme un motif distinct lorsqu'il ne s'agit que d'une simple implémentation d'Observer. En repensant à ce que je faisais à l'époque, je me souviens d'avoir travaillé sur la logique pour rester assis derrière une interface assez complexe avec un certain nombre de panneaux différents avec des données interdépendantes. L'utilisateur peut modifier les valeurs et / ou exécuter une routine d'optimisation et, en fonction de ces actions, des événements sont générés que l'interface utilisateur écoute et met à jour si nécessaire. Il y avait un certain nombre de problèmes au cours du développement où certains panneaux ne mettraient pas à jour quand ils le devraient. La solution (rester dans la conception) était de générer des événements à partir d'autres événements. En fin de compte, au moment où tout fonctionnait correctement, presque chaque changement a eu pour conséquence de rafraîchir tous les panneaux. Toute la difficulté d'essayer d'isoler lorsqu'un groupe donné avait besoin d'actualiser n'avait servi à rien. Et ça n'avait pas d'importance quand même. C'était effectivement une optimisation prématurée. J'aurais économisé une tonne de temps et d'efforts en réduisant simplement le tout en un seul événement qui a tout rafraîchi.
Il existe d'innombrables systèmes conçus dans le «tout réparer» ou tout rafraîchir. Pensez à toutes les interfaces CRUD qui ajoutent / mettent à jour une ligne, puis actualisent à nouveau la base de données. Ce n'est pas une approche exotique, c'est juste la solution évidente non intelligente. Vous devez comprendre qu'en 2003, c'était le comble de la «fièvre de modèle». D'après ce que je pouvais dire, les gens pensaient que nommer de nouveaux modèles serait un chemin vers la gloire et la richesse. Ne vous méprenez pas, je pense que le concept de motif est extrêmement utile pour décrire des solutions abstraites. Les choses ont tout simplement déraillé. C'est malheureux parce que cela a créé beaucoup de cynisme à propos du concept de motif en général. Ce n'est que dans ce contexte qu'il est logique de parler de solution "peu orthodoxe". Il' s semblable à l'orthodoxie autour des ORM ou des conteneurs DI. Ne pas les utiliser est considéré comme peu orthodoxe, alors que les gens construisaient des logiciels bien avant que ces outils n'existent et, dans de nombreux cas, ces outils sont excessifs.
Revenons donc à 'tout réparer'. Un exemple simple est le moyen de calcul. La solution simple consiste à totaliser et diviser par la cardinalité des valeurs. Si vous ajoutez ou modifiez un numéro, il vous suffit de le refaire depuis le début. Vous pouvez garder la trace de la somme et du nombre de chiffres et quand quelqu'un ajoute un nombre, vous augmentez le nombre et l'ajoutez à la somme. Maintenant, vous ne ré-ajoutez pas tous les chiffres. Si vous avez déjà travaillé avec Excel avec une formule faisant référence à une plage et modifié une valeur unique dans cette plage, vous avez un exemple du modèle 'Tout corriger', c'est-à-dire que toute formule faisant référence à cette plage sera recalculée indépendamment du fait que cette valeur était pertinente (par exemple, en utilisant quelque chose comme sumif ()).
Cela ne veut pas dire que ce n’est pas un choix judicieux dans un contexte donné. Dans l'exemple moyen, disons que nous devons maintenant prendre en charge les mises à jour. Maintenant, j'ai besoin de connaître l'ancienne valeur et de ne changer que la somme par le delta. Rien de tout cela n'est vraiment difficile tant que vous n'envisagez pas d'essayer de le faire dans un environnement distribué ou concurrent. Vous devez maintenant gérer toutes sortes de problèmes épineux de synchronisation et vous allez probablement créer un goulot d'étranglement majeur qui ralentit les choses beaucoup plus que de recalculer.
Le résultat est que l’approche «tout réparer» ou «tout rafraîchir» est beaucoup plus facile à obtenir. Vous pouvez faire fonctionner une approche plus sophistiquée, mais elle est beaucoup plus compliquée et donc plus susceptible d’être viciée. En outre, dans de nombreux contextes, l’approche consistant à «actualiser tout» peut être plus efficace. Par exemple, les approches de copie à l'écriture sont généralement plus lentes pour les approches à un seul thread, mais lorsque vous avez une simultanéité élevée, cela peut vous permettre d'éviter les verrous et donc d'améliorer les performances. Dans d'autres cas, cela peut vous permettre de regrouper les modifications par lot de manière efficace. Donc, pour la plupart des problèmes, vous voudrez probablement commencer par une approche de tout actualiser, sauf si vous avez une raison spécifique pour laquelle vous ne pouvez pas le faire, puis vous inquiétez de faire quelque chose de plus complexe une fois que vous en avez besoin.