Creo que el artículo está un poco anticuado porque, al leerlo, no es una idea poco ortodoxa o nueva. Esta idea se presenta como un patrón separado cuando realmente es solo una implementación simple de Observer. Pensando en lo que estaba haciendo en ese momento, recuerdo trabajar en la lógica para sentarme detrás de una interfaz algo compleja con varios paneles diferentes con datos que eran interdependientes. El usuario podría cambiar los valores y / o ejecutar una rutina de optimización y, en función de esas acciones, se generaron eventos que la interfaz de usuario escucharía y actualizaría según fuera necesario. Hubo una serie de problemas durante el desarrollo en los que ciertos paneles no se actualizaron cuando deberían. La solución (permanecer dentro del diseño) fue generar eventos a partir de otros eventos. Finalmente, para cuando todo funcionaba bien, Casi todos los cambios dieron como resultado la actualización de todos los paneles. Toda la complejidad de tratar de aislar cuando un panel determinado necesitaba actualizarse fue en vano. Y no importó de todos modos. Fue efectivamente una optimización prematura. Hubiera ahorrado un montón de tiempo y esfuerzo simplemente colapsando todo en un solo evento que refrescó todo.
Hay innumerables sistemas diseñados en el "arreglar todo" o actualizar todo. Piense en todas las interfaces CRUD que agregan / actualizan una fila y luego solicitan la base de datos. Este no es un enfoque exótico, es solo la obvia solución no inteligente. Tienes que darte cuenta de que en 2003, era el colmo de la "fiebre del patrón". Por lo que pude ver, la gente pensó que nombrar nuevos patrones sería su camino hacia la fama y la riqueza. No me malinterpreten, creo que el concepto de un patrón es extremadamente útil para describir soluciones en abstracto. Las cosas se salieron un poco de los rieles. Es lamentable porque creó mucho cinismo sobre el concepto de patrón en general. Es solo en este contexto que tiene sentido hablar de esto como una solución 'poco ortodoxa'. Eso' s similar a la ortodoxia alrededor de los ORM o contenedores DI. No usarlos se considera poco ortodoxo a pesar de que las personas habían estado construyendo software mucho antes de que existieran estas herramientas y, en muchos casos, esas herramientas son excesivas.
Así que volvamos a 'arreglar todo'. Un ejemplo simple es calcular medios. La solución simple es sumar números y dividirlos por la cardinalidad de los valores. Si agrega o modifica un número, simplemente vuelva a hacerlo, desde el principio. Puede realizar un seguimiento de la suma y el recuento de números y cuando alguien agrega un número, aumenta el recuento y lo agrega a la suma. Ahora no está volviendo a agregar todos los números nuevamente. Si alguna vez trabajó con Excel con una fórmula que hace referencia a un rango y modificó un solo valor en ese rango, tiene un ejemplo del patrón 'arreglar todo', es decir, cualquier fórmula que tenga una referencia a ese rango volverá a calcular independientemente de si ese valor era relevante (por ejemplo, usando algo como sumif ()).
Esto no quiere decir que no sea una elección inteligente en un contexto dado. En el ejemplo, digamos que ahora necesitamos admitir actualizaciones. Ahora necesito saber el valor anterior de alguna manera y solo cambiar la suma por el delta. Nada de esto es realmente tan desafiante hasta que considere intentar hacer esto en un entorno distribuido o concurrente. Ahora tiene que manejar todo tipo de problemas de tiempo espinoso y probablemente terminará creando un cuello de botella importante que ralentiza las cosas mucho más que volver a calcular.
El resultado aquí es que es mucho más fácil acertar con el enfoque de "arreglar todo" o "actualizar todo". Puede hacer que un enfoque más sofisticado funcione, pero es mucho más complicado y, por lo tanto, es más probable que tenga fallas. Además, en muchos contextos, el enfoque de "actualizar todo" puede ser más eficiente. Por ejemplo, los enfoques de copia en escritura son generalmente más lentos para los enfoques de subproceso único, pero cuando tiene una alta concurrencia, puede permitirle evitar bloqueos y, por lo tanto, proporcionar un mejor rendimiento. En otros casos, puede permitirle agrupar cambios de manera eficiente. Entonces, para la mayoría de los problemas, es probable que desee comenzar con un enfoque de actualización de todo, a menos que tenga una razón específica por la que no puede hacerlo y luego se preocupe por hacer algo más complejo una vez que lo necesite.