この記事は少し古くなっていると思います。これを読んだとき、これはまったく正統的でも新しいアイデアでもないからです。このアイデアは、実際には単なるObserverの実装である場合、別のパターンとして提示されます。当時のことを考えてみると、相互に依存するデータを含むさまざまなパネルを備えたやや複雑なインターフェイスの背後にあるロジックに取り組んだことを覚えています。ユーザーは値を変更したり、最適化ルーチンを実行したりすることができ、それらのアクションに基づいて、UIが必要に応じてリッスンして更新するイベントが生成されました。開発中に、特定のパネルが必要なときに更新されないという問題がいくつかありました。修正（設計内にとどまる）は、他のイベントからイベントを生成することでした。最終的に、すべてが正常に機能するまでに、ほとんどすべての変更により、すべてのパネルが更新されました。特定のパネルを更新する必要があるときに隔離しようとする複雑さは、すべて無駄でした。とにかく問題ではありませんでした。事実上、時期尚早の最適化でした。すべてをすべてを更新する単一のイベントに折りたたむだけで、時間と労力を大幅に節約できます。
「すべてを修正」またはすべてを更新する方法で設計された無数のシステムがあります。行を追加/更新してからDBを再クエリするすべてのCRUDインターフェイスを考えてください。これはエキゾチックなアプローチではなく、明らかな非賢いソリューションです。2003年には、それが「パターンフィーバー」の高さだったことに気づかなければなりません。私が言えることから、人々は新しいパターンの命名が名声と富への道になると考えていました。誤解しないでください。パターンの概念は、抽象でソリューションを説明するのに非常に役立つものだと思います。ちょっと物事は少しレールから外れました。それは一般的にパターンの概念について多くの皮肉を作成したため、それは残念です。これを「非正統的」な解決策として語ることが理にかなっているのは、この文脈においてのみです。それ' ■ORMまたはDIコンテナの正統性に似ています。これらのツールが存在するずっと前に人々がソフトウェアを構築していたにもかかわらず、それらを使用しないことは非正統的と見なされ、多くの場合、これらのツールは過剰です。
「すべてを修正する」に戻ります。簡単な例は、平均の計算です。簡単な解決策は、数値を合計し、値の基数で除算することです。番号を追加または変更する場合、最初からやり直します。合計と数字のカウントを追跡し、誰かが数字を追加すると、カウントを増やして合計に追加します。これで、すべての数値を再度追加することはありません。範囲を参照し、その範囲内の単一の値を変更する数式でExcelを使用したことがある場合、「すべてを修正」パターンの例があります。つまり、その範囲への参照を持つ数式は、その値は関連していました（例：sumif（）のようなものを使用）。
これは、これが特定のコンテキストで賢明な選択ではないということではありません。平均的な例では、更新をサポートする必要があるとしましょう。ここで、古い値を何らかの方法で知り、合計をデルタだけ変更する必要があります。分散環境または同時実行環境でこれを行うことを検討するまで、これは実際にそれほど難しくありません。今、あらゆる種類の厄介なタイミングの問題に対処する必要があり、おそらく再計算よりもはるかに遅くなる大きなボトルネックを作成することになります。
ここでの結論は、「すべてを修正する」または「すべてを更新する」アプローチがはるかに簡単になることです。より洗練されたアプローチを機能させることができますが、はるかに複雑であるため、欠陥が発生する可能性が高くなります。さらに、多くのコンテキストで、「すべてをリフレッシュ」アプローチの方が効率的です。たとえば、コピーオンライトアプローチは、シングルスレッドアプローチでは一般に低速ですが、同時実行性が高い場合、ロックを回避できるため、パフォーマンスが向上します。また、効率的な方法で変更をまとめてバッチ処理できる場合もあります。そのため、ほとんどの問題では、それができない特定の理由がない限り、すべてをリフレッシュするアプローチから始めて、必要になったらもっと複雑なことをすることを心配するでしょう。