It is a long post with a lot of good points. One minor thing I would argue: the "setter support" in languages is not really a plus for observer patterns. In ma

It is a long post with a lot of good points. One minor thing I would argue: the "setter support" in languages is not really a plus for observer patterns. In many such languages support "setter" and use such to naively implement observer patterns, you can see a lot of repeated updates for the same object through the call chains. Because often than not, you are not update one property for one state object, you need to update a set of properties across some number of state objects, and simplistic "setter" based observation cannot differentiate these and coalescing properly. People can workaround this and implement "backpressure" etc, but it just to add more complexity on a broken promises. What you really need is an observer implementation with transactional guarantees. Thus, the state change cannot be observed until an update transaction is done. This will naturally reduce number of unnecessary updates, and doesn't really need "setter support" from the language.