The observer pattern
As we advance in this book, we keep mentioning how important decoupling is. When we reduce dependencies, we can extend, develop, and test different modules without having to know the implementation details of other modules. All we have to know is the abstraction they implement.
However, modules should work together in practice. And it's not uncommon that changes in one object are known by another object. For example, if we implement a car class in a game, the engine of the car should know when the accelerator changes its position. The naive solution would be to have an engine class that checks from time to time the accelerator position to see whether it has changed. A smarter approach would be to make the accelerator call the engine to inform it about the changes. But this is not enough if we want to have well-designed code.
If the Accelerator class keeps a reference to the Engine class, what happens when we need to display on screen the position of Accelerator? This is...
