Creo que el artículo está un poco anticuado porque, mientras lo leo, esta no es realmente una idea poco ortodoxa o nueva. Esta idea se presenta como un patrón separado cuando en realidad es solo una implementación simple de Observer. Recordando lo que estaba haciendo en ese momento, recuerdo que trabajé en 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 donde ciertos paneles no se actualizaron cuando deberían. La solución (permanecer dentro del diseño) era generar eventos de otros eventos. En última instancia, cuando todo funcionaba bien, casi todos los cambios resultaron en la actualización de todos los paneles. La complejidad de tratar de aislar cuando un panel dado necesitaba actualizarse fue en vano. Y no importaba de todos modos. Fue efectivamente una optimización prematura. Habría ahorrado un montón de tiempo y esfuerzo simplemente al colapsarlo todo en un solo evento que lo actualizó todo.
Hay innumerables sistemas diseñados en "arreglar todo" o actualizar todo. Piense en todas las interfaces CRUD que agregan / actualizan una fila y luego vuelva a consultar la base de datos. Este no es un enfoque exótico, es solo la solución obvia no inteligente. Tienes que darte cuenta de que en 2003, fue la altura de la "fiebre de patrón". Por lo que pude ver, la gente pensó que nombrar nuevos patrones iba a ser su camino hacia la fama y la riqueza. No me malinterpretes, creo que el concepto de patrón es extremadamente útil para describir soluciones en abstracto. Las cosas simplemente se salieron un poco de los rieles. Es desafortunado 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". Es similar a la ortodoxia alrededor de los ORM o los contenedores DI. No usarlos se considera poco ortodoxo, aunque la gente había estado creando 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 los medios. La solución simple es sumar números y dividir por la cardinalidad de los valores. Si agrega o modifica un número, simplemente hágalo nuevamente, desde el principio. Puede hacer 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ás volviendo a agregar todos los números otra vez. Si alguna vez ha trabajado 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 se recalculará 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 medio, digamos que ahora necesitamos soportar actualizaciones. Ahora necesito saber el valor antiguo de alguna manera y solo cambiar la suma por el delta. Nada de esto es realmente tan desafiante hasta que considere tratar de hacer esto en un entorno distribuido o concurrente. Ahora tiene que manejar todo tipo de problemas de tiempo espinoso y es probable que termine creando un gran cuello de botella que ralentiza las cosas mucho más que recalcular.
El resultado final aquí es que el enfoque de 'arreglar todo' o 'actualizar todo' es mucho más fácil de hacer. Puede hacer que un enfoque más sofisticado funcione, pero es mucho más complicado y por lo tanto es más probable que sea defectuoso. 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 un solo hilo, pero cuando tiene una alta concurrencia, puede permitirle evitar bloqueos y, por lo tanto, proporcionar un mejor rendimiento. En otros casos, puede permitirle realizar cambios por lotes de manera eficiente. Por lo tanto, para la mayoría de los problemas, probablemente desee comenzar con un enfoque de actualización de todo a menos que tenga una razón específica por la que no pueda hacerlo y luego preocuparse por hacer algo más complejo una vez que tenga una necesidad. Una implementación de trabajo contra la que puede realizar una prueba de regresión es valiosa en sí misma, incluso si es lenta.