Menu
I'm studying for an exam and are currently reading about the observer pattern. Then I was wondering what SOLID principles the observer pattern follows or violates?
273
In general, the most relevant SOLID principle related to Observer is the Open/Close Principle: Once you have written the code of the observed object, you need not change the code when you want additional observers to know it, yet it is easy to add such observers - this is exactly what "closed for modifications, open ...
The Observer pattern addresses the following problems: A one-to-many dependency between objects should be defined without making the objects tightly coupled. It should be ensured that when one object changes state, an open-ended number of dependent objects are updated automatically.
Disadvantages of Observer Design Pattern The main disadvantage of the observer design pattern that subscribers are notified in random order. There is also a memory leakage problem in the observer design pattern because of the observer's explicit register and unregistering.
Which SOLID principle is violated in the following code? I think that LSP (Liskov Substitution Principle) is violated because the subclass B cannot be substituted into a variable of type A .
Design patterns are - as their name implies - only patterns. Their actual implementation might highly differ among various applications.
In general, the most relevant SOLID principle related to Observer is the Open/Close Principle: Once you have written the code of the observed object, you need not change the code when you want additional observers to know it, yet it is easy to add such observers - this is exactly what "closed for modifications, open for extensions" mean.
It might also be considered an application of the Dependency Inversion Principle: The observed subject enforces a known API in which whoever wants to observe it must follow some rules, and in particular, the observed subject will call their update() function instead of calling the observers' specific functions. That way, if the observers are to be changed, the observed class has nothing to do (compare that to the option of calling a specific observer function).
In the basic, classical implementation (i.e., the one from GoF), there might be violations of SRP and ISP.
In that implementation, the object that is being changed is responsible for updating the observers. This is another responsibility that the class holds, in addition to its main responsibility. Thus, there is more then a single "reason" to update the class in the future - if the updating mechanism has to be changed (e.g. use a different container, use thread-safe mechanism, etc.) - the change will take place on the same class that has a completely different main responsibility. Of course, this can be solved by separating the "Observer" mechanism to another class.
Another possible SOLID violation by the simplistic implementation is that according to that implementation of the GoF, each updated observer should then inspect the status of the observed subject to detect a change. That might mean there is no interface segregation since any observer should be exposed to everything in the observed subject. However, it does not have to work that way, and it is very easy to provide a bit more sophisticated implementations that use different interfaces to different observers.
The pattern has not much to do with the Liskov Substitution Principle - as long as inheritance (e.g. inheriting the observer and the observed types by concrete types) does not do something they shouldn't, that principle will be kept.
172
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
