What is the “Fix Everything” design pattern?

Let's say you have an HTML page that is fairly complicated-- if you pick something in one dropdown, another control might appear, or the values in a third control might change. There's two ways you could approach this:

1. Write a separate handler, for each and every control, that respond to events on that control, and updates other controls as needed.

2. Write a single handler that looks at the state of all the controls on the page and just fixes everything.

The second call is "idempotent" because you can call it over and over again and the controls will always be arranged properly. Whereas the first call(s) may have issues if a call is lost or repeated, e.g. if one of the handlers performs a toggle.

The logic for the second call would be a bit more obscure, but you only have to write one handler.

And you can always use both solutions, calling the "fix everything" function as needed "just to be on the safe side."

The second approach is especially nice when state can come from different sources, e.g. from user input versus rendered from the server. In ASP.NET, the technique plays very well with the concept of postback because you just run the fix everything function whenever you render the page.

Now that I've mentioned events being lost or repeated, and getting state from different sources, I'm thinking it is obvious how this approach maps well to a problem space like BitTorrent's.

Cons? Well the obvious con is that there is a performance hit because it is less efficient to go over everything all the time. But a solution like BitTorrent is optimized to scale out, not scale up, so it's good for that sort of thing. Depending on the problem you are trying to solve, it might not be suitable for you.

I think the article is a bit dated because as I read it, this isn't really a unorthodox or new idea at all. This idea is presented as a separate pattern when it really is just a simple Observer implementation. Thinking back to what I was doing at the time, I remember working on logic to sit behind a somewhat complex interface with a number of different panels with data that were interdependent. The user could change values and/or run a optimization routine and based on those actions, events were generated that the UI would listen to and update as needed. There were a number of issues during development where certain panels wouldn't update when they should. The fix (staying within the design) was to generate events from other events. Ultimately, by the time everything was working right, almost every change resulted in all the panels to refresh. All the complexity of trying to isolate when a given panel needed to refresh was for naught. And it didn't matter anyway. It was effectively a premature optimization.

There are innumerable systems designed this way. Think of all the CRUD interfaces that add/update a row and then requery the DB. This isn't an exotic approach, it's just the obvious non-clever solution.

A simple example is calculating means. The simple solution is to sum numbers and divide by the cardinality of the values. If you add or modify a number, you just do it again, from the beginning. You could keep track of the sum and the count of numbers and when someone adds a number, you increase the count and add it to the sum. Now you aren't re-adding all the numbers again. If you've ever worked with Excel with a formula that references a range and modified a single value in that range, you have an example of the 'fix everything' pattern i.e. any formula that has a reference to that range will recalculate regardless of whether that value was relevant (e.g. using something like sumif()).

This isn't to say this isn't a smart choice in a given context. In the mean example, lets say we now need to support updates. Now I need to know the old value somehow and only change the sum by the delta. None of this is really that challenging until you consider trying to do this in a distributed or concurrent environment. You now have to handle all kinds of thorny timing issues and you'll likely end up creating a major bottleneck which slows down things far more than recalculating.

Not sure it's a "design pattern", but I would classify that type of behavior as end state configuration or desired state configuration, in the vein of Puppet, Chef or Powershell DSC.

Those solutions typically operate at the systems management level, not a business logic level as the question describes, but it's the effectively the same paradigm, and although such tools are usually declarative in nature, the same principles can be applied in procedural code or scripting.