8
For testing purposes, I am porting an application from version 7 to version 9 of Java.
This application has some features that use Observer and Observable.
I realized that both became obsolete:
@Deprecated(since="9") public class Observable extends Object
@Deprecated(since="9") public interface Observer
9
Like every function that becomes obsolete, they did not meet the needs well, were poorly designed and now have better solutions.
These types were too general, did not carry important information about the event and were not so safe from the point of view of typing.
The staff complained that they were not able to handle competition and serialize the object.
Official position:
They don’t provide a rich enough Event model for Applications. For example, they support only the notion that Something has changed, but they don’t Convey any information about what has changed. There are also some thread-Safety and sequencing issues that cannot be Fixed compatibly.
The whole pattern was poorly thought out. That’s why you gotta watch out for Patterns design.
One of the alternatives is PropertyChangeListener which is usually more specific, simpler and is what you want.
If you need something more powerful you can use the class Flow. The very documentation indicates this.
2
The creation of the Observer is credited, according to Martin Fowler, to the implementation of MVC in Smalltalk (see GUI Architectures). The central idea of the pattern is to notify observers when any observable is in a state of interest to observers. In the case of MVC, the models were observable and the views observant. When the model changed, the view was notified and changed what was displayed to the user.
None (none perhaps is too strong) design pattern is, in essence, bad. There are scenarios in which its use can be interesting and others in which it does not. It is always important to evaluate the pros and cons, as well as alternatives, when choosing between one standard or another.
In the case of Java, as Maniero mentioned, Oracle mentions as motivation to render the components obsolete mainly the fact that there is no guaranteed order for notification of observers (which may be a problem).
But the fact that Oracle has rendered the components obsolete does not mean that you should stop using the standard. The implementation of Observable and Observer in Java is very simple. It is not difficult to create a version of you that fixes the problems mentioned by Oracle.
In the link mentioned by Maniero with reasons not to use the Observer, there are several criticisms that apply much more to the example that the author of the post chose to give than to the characteristics of the pattern, to name but a few:
Side-effects Observers don’t have to be stateless. I don’t think there’s any mention of it in the Gof book, but even if there is, it’s a suggestion of how to use, not a rule.
Encapsulation For the example that the author gave, yes, but in the very doctored example of vision (MVC), there is no encapsulation break.
Composability The need to discard multiple observers at the same time is much more a specific domain demand than a general rule that might belittle the pattern.
Separation of Concerns Here the author of the post suggests using the MVC, perhaps not knowing that its original implementation provided precisely the Observer...
As to the Propertychangelistener, One point to note is that it treats changes in properties individually rather than together, as a more generic implementation of the Observer would allow it to do. If this is your context, take good care.
Browser other questions tagged java pattern-design characteristic-language observer-pattern java-9
You are not signed in. Login or sign up in order to post.