Eu acho que o artigo está um pouco datado porque, ao lê-lo, isso não é realmente uma idéia nada ortodoxa ou nova. Essa ideia é apresentada como um padrão separado quando, na verdade, é apenas uma simples implementação do Observador. Pensando no que eu estava fazendo na época, lembro de trabalhar na lógica para me sentar atrás de uma interface um tanto complexa com vários painéis diferentes com dados interdependentes. O usuário pode alterar valores e / ou executar uma rotina de otimização e, com base nessas ações, foram gerados eventos que a interface do usuário ouve e atualiza conforme necessário. Houve vários problemas durante o desenvolvimento em que determinados painéis não foram atualizados quando deveriam. A correção (permanecendo dentro do design) era gerar eventos de outros eventos. Por fim, quando tudo estava dando certo, quase todas as mudanças resultavam em todos os painéis para atualizar. Toda a complexidade de tentar isolar quando um determinado painel precisava atualizar foi em vão. E isso não importava de qualquer maneira. Foi efetivamente uma otimização prematura. Eu teria economizado muito tempo e esforço simplesmente juntando tudo em um único evento que refrescou tudo.
Existem inúmeros sistemas projetados no "consertar tudo" ou atualizar tudo. Pense em todas as interfaces CRUD que adicionam / atualizam uma linha e, em seguida, voltam a consultar o banco de dados. Esta não é uma abordagem exótica, é apenas a solução óbvia não inteligente. Você tem que perceber que, em 2003, foi o auge da "febre padrão". Pelo que eu poderia dizer, as pessoas achavam que nomear novos padrões seria o caminho para a fama e a riqueza. Não me entenda mal, acho que o conceito de um padrão é extremamente útil para descrever soluções abstratas. As coisas meio que saíram dos trilhos um pouco. É uma pena porque criou muito cinismo sobre o conceito de padrão em geral. É somente nesse contexto que faz sentido falar sobre isso como uma solução "não ortodoxa". É semelhante à ortodoxia em torno de ORMs ou contêineres DI. Não usá-los é visto como heterodoxo, embora as pessoas estivessem construindo software muito antes de essas ferramentas existirem e, em muitos casos, essas ferramentas são exageradas.
Então, de volta para "consertar tudo". Um exemplo simples é calcular meios. A solução simples é somar números e dividir pela cardinalidade dos valores. Se você adicionar ou modificar um número, basta fazê-lo novamente, desde o início. Você pode acompanhar a soma e a contagem de números e, quando alguém adiciona um número, você aumenta a contagem e adiciona à soma. Agora você não está adicionando novamente todos os números novamente. Se você já trabalhou com o Excel com uma fórmula que referencia um intervalo e modificou um único valor nesse intervalo, você tem um exemplo do padrão 'corrigir tudo', ou seja, qualquer fórmula que tenha uma referência a esse intervalo será recalculada, independentemente de esse valor era relevante (por exemplo, usando algo como sumif ()).
Isso não quer dizer que isso não seja uma escolha inteligente em um determinado contexto. No exemplo médio, digamos que agora precisamos dar suporte a atualizações. Agora eu preciso saber o valor antigo de alguma forma e apenas alterar a soma pelo delta. Nada disso é realmente tão desafiador até você considerar tentar fazer isso em um ambiente distribuído ou concorrente. Agora você tem que lidar com todos os tipos de problemas espinhosos de tempo e você provavelmente acabará criando um grande gargalo que retarda as coisas muito mais do que recalcular.
O resultado aqui é que a abordagem 'corrigir tudo' ou 'atualizar tudo' é muito mais fácil de acertar. Você pode fazer um trabalho de abordagem mais sofisticado, mas é muito mais complicado e, portanto, mais propenso a ser falho. Além disso, em muitos contextos, a abordagem "atualizar tudo" pode ser mais eficiente. Por exemplo, as abordagens de cópia em gravação geralmente são mais lentas para abordagens de encadeamento único, mas quando você tem alta simultaneidade, pode evitar bloqueios e, portanto, fornecer melhor desempenho. Em outros casos, pode permitir que você faça alterações em lote de maneira eficiente. Portanto, para a maioria dos problemas, você provavelmente quer começar com uma abordagem de atualização de tudo, a menos que tenha uma razão específica para não conseguir fazer isso e, em seguida, se preocupe em fazer algo mais complexo quando tiver necessidade. Uma implementação funcional com a qual você pode testar a regressão é valiosa por si só, mesmo que seja lenta.