I’m reading about design patterns from both “Head First Design Patterns” and the original “Elements of reusable software etc” and I’m finding some confusion right at the start, in the Observer pattern.
Both books depict a diagram with two abstract classes/interfaces, Subject and Observer, distinct from their implementation, ConcreteSubject and ConcreteObserver. This is justified with keeping the two components loosely coupled. I can’t quite figure an example where the Subject would need to be abstract, but I’m sure there are some applications out there.
My real issue is in the concrete implementations: there is a directed association from the ConcreteObserver to the ConcreteSubject. It’s explained that this is due to the update() function (and the Observer interface) not knowing about the Subject, so the ConcreteObserver has to interact with the ConcreteSubject to inquire about the nature of the change.
Doesn’t this directed association negate the Subject abstraction? What use is there in keeping Observer and Subject loosely coupled if ConcreteObserver has to depend on ConcreteSubject?
Maldus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1