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 the best solution: instead of making the accelerator dependent on the engine, we should make both of them rely on abstractions.