Recommended Link: Deprecating the Observer Pattern
by Malte Skarupke
A note about this post: I sometimes feel like I should have a Twitter account just to share random links, but I’d also like something more organized than Twitter. So I think I’ll just post short blog posts here every now and then which are basically just a link and a comment about the link. Let’s start with Deprecating the Observer Pattern:
One of my favourite papers. After you’ve read it here’s my comments:
– This clarified for me how much value you can get just out of abstracting a pattern. The part “Many classes in Java Swing, for instance, contain a addChangeListener or addActionListener method per convention. We can factor out a common interface in Scala.React using Scala’s traits.” looks innocent but is actually very important. People have reimplemented the observer pattern in Java hundreds of times. It doesn’t look bad because it’s simple and fast to do so. But once somebody took the time to abstract it, you start thinking differently. See also the addition of lambdas and std::function to the C++ standard, and how available libraries have changed since then. How often do you reimplement the observer pattern in your engine? How would your code simplify and your thinking change if, say the update loop, the render loop, your auto save and your physics collision callbacks all used the same (or similar) implementations of the observer pattern?
– This paper was one of the things that convinced me that callstacks are a bit annoying. The transformation in chapter 3 of the paper requires some really clever trickery to get away from the unpredictable control flow of the observer pattern to something more normal, linear. They probably also sacrifice a lot of performance. The actual work being done here is not hard though. The final code is straight forward and it should be trivial to express this in all languages. We only make it much harder than it should be because of accidental complication, in part because of the callstack abstraction.