Few Thoughts on 'Deprecating the Observer Pattern'

When this article was brought to my attention, I thought ‘wow, not much hubris there: let‘s go put a toe tag on a piece of the most important computer book of the last 2 decades.‘ Then I started to read it and realized that, what a surprise, the engineers are not very good writers and they are not really sure what they are shoving aside. If there are any reasons to think about banishing Observer, they are certainly not set forth in this article. Instead, what we get is a quick little misprision where the train tracks are switched and unbeknownst to the authors, we end up with a diatribe against a particular version of event-based programming: one where Observer is used as the modus operandi. That‘s all.

One of the funniest things about this piece is that it starts with some metrics observations from Adobe. Um, Folks, I would probably put Adobe at the bottom of the pile of places whose advice about development was going to make me start thinking about burning books (maybe with only Microsoft underneath them). Furthermore, the whole thing reads comically like Mr. Magoo describing the acute details of configuring a sophisticated industrial process: 1/3 of the code in Adobe's desktop applications is devoted to event handling logic, 1/2 of the bugs reported are in this code. So, first off, sounds like that code is only slightly more faulty than one would expect, no? So instead of accounting for a third of the bugs, it accounted for half. But then, the authors go on to claim that they think with some good behavior, they can reduce the code 3:1, and that will bring the defect density in line. Reminds me of the Woody Allen line from Take the Money and Run ‘Virgil Starkwell is tried on fifty-two counts of robbery and is sentenced to eight hundred years in federal prison. At the trial, he tells his lawyer confidentially that with good behavior he can cut the sentence in half.‘

What transpires, though, after the reader is blindfolded and spun around, is that the authors proceed to simply trot out another design pattern (without credit): the Reactor Pattern. Doug Schmidt introduced this in the second PLoP book. It‘s a great pattern. It has a demultiplexer and a dispatcher, which, according to these guys, solves all their problems.

Why have patterns not been absorbed adequately by the development community, 17 years later? This is one reason: people treat them not as a recipe, but as an edict or set of commandments, and there‘s no ability to see families of them, to understand tradeoffs, instead, we get reductive nonsense. Yeah, we need to throw out Observer. Because there are event cases that call for another pattern. Please…. BTW, I use Observer for, um, cases where the participating party is, um Observing. What does that word imply? Not an active role in what is transpiring, but rather needing only some immutable context notifications so it might update it‘s own view of the world.

Deprecating Observer Article
The Reactor Pattern

From http://www.jroller.com/robwilliams/entry/few_thoughts_on_deprecating_the