Penso che l'articolo sia un po 'datato perché mentre lo leggo, questa non è affatto un'idea affatto ortodossa o nuova. Questa idea è presentata come un modello separato quando è solo una semplice implementazione di Observer. Ripensando a quello che stavo facendo in quel momento, ricordo di aver lavorato sulla logica per sedermi dietro un'interfaccia piuttosto complessa con un numero di pannelli diversi con dati che erano interdipendenti. L'utente può modificare i valori e / o eseguire una procedura di ottimizzazione e in base a tali azioni, sono stati generati eventi che l'interfaccia utente ascolta e aggiorna secondo necessità. Durante lo sviluppo si sono verificati numerosi problemi in cui alcuni pannelli non si aggiornavano quando avrebbero dovuto. La correzione (rimanendo all'interno del progetto) era di generare eventi da altri eventi. Alla fine, quando tutto ha funzionato correttamente, quasi tutti i cambiamenti hanno comportato l'aggiornamento di tutti i pannelli. Tutta la complessità del tentativo di isolare quando un determinato pannello doveva essere aggiornato era inutile. E non importava comunque. Era in effetti un'ottimizzazione prematura. Avrei risparmiato un sacco di tempo e fatica semplicemente collassando tutto in un singolo evento che ha rinfrescato tutto.
Esistono innumerevoli sistemi progettati in "aggiustare tutto" o aggiornare in qualsiasi modo. Pensa a tutte le interfacce CRUD che aggiungono / aggiornano una riga e quindi eseguono la query sul DB. Questo non è un approccio esotico, è solo l'ovvia soluzione non intelligente. Devi rendertene conto che nel 2003 era il culmine della "febbre da modello". Da quello che ho potuto dire, la gente pensava che nominare nuovi modelli sarebbe stato il loro percorso verso la fama e la ricchezza. Non fraintendermi, penso che il concetto di un modello sia estremamente utile per descrivere le soluzioni in astratto. Le cose sono andate un po 'fuori dai binari. È sfortunato perché ha creato molto cinismo riguardo al concetto di modello in generale. È solo in questo contesto che ha senso parlare di questa come una soluzione "non ortodossa". È simile all'ortodossia attorno agli ORM o ai contenitori DI. Non usarli è considerato non ortodosso anche se la gente aveva costruito software molto prima che questi strumenti esistessero e in molti casi quegli strumenti sono eccessivi.
Quindi torna a 'aggiustare tutto'. Un semplice esempio è il calcolo dei mezzi. La soluzione semplice è sommare i numeri e dividere per la cardinalità dei valori. Se aggiungi o modifichi un numero, lo fai di nuovo, dall'inizio. Puoi tenere traccia della somma e del conteggio dei numeri e quando qualcuno aggiunge un numero, aumenti il conteggio e lo aggiungi alla somma. Ora non stai aggiungendo di nuovo tutti i numeri. Se hai mai lavorato con Excel con una formula che fa riferimento a un intervallo e modificato un singolo valore in quell'intervallo, hai un esempio del modello "aggiusta tutto", ovvero qualsiasi formula che abbia un riferimento a quell'intervallo verrà ricalcolata indipendentemente dal fatto quel valore era rilevante (es. usando qualcosa come sumif ()).
Questo non vuol dire che questa non è una scelta intelligente in un dato contesto. Nell'esempio medio, diciamo che ora dobbiamo supportare gli aggiornamenti. Ora ho bisogno di conoscere il vecchio valore in qualche modo e solo modificare la somma per il delta. Niente di tutto questo è davvero così impegnativo finché non si considera di provare a farlo in un ambiente distribuito o concorrente. Ora devi gestire tutti i tipi di problemi di temporizzazione spinosi e probabilmente finirai per creare un collo di bottiglia importante che rallenta molto di più il ricalcolo.
Il risultato è che l'approccio "aggiusta tutto" o "aggiorna tutto" è molto più facile da ottenere. Puoi far funzionare un approccio più sofisticato ma è molto più complicato e quindi più probabile che sia difettoso. Inoltre, in molti contesti, l'approccio "aggiorna tutto" può essere più efficiente. Ad esempio, gli approcci di copia su scrittura sono generalmente più lenti per gli approcci a thread singolo, ma quando si dispone di una concorrenza elevata, è possibile evitare i blocchi e quindi fornire prestazioni migliori. In altri casi, può consentire di eseguire modifiche in gruppo in modo efficiente. Quindi, per la maggior parte dei problemi, probabilmente vorrai iniziare con un approccio di aggiornamento a meno che tu non abbia una ragione specifica per cui non puoi farlo e quindi preoccuparti di fare qualcosa di più complesso una volta che ne hai bisogno. Un'implementazione funzionante alla quale è possibile eseguire un test di regressione è di per sé preziosa, anche se è lenta.