I just noticed that java.util.Observable is a concrete class. Since the purpose of Observable is to be extended, this seems rather odd to me. Is there a reason why it was implemented this way?
I found this article which says that
The observable is a concrete class, so the class deriving from it must be determined upfront, as Java allows only single inheritance.
But that doesn't really explain it to me. In fact, if Observable were abstract, the user would be forced to determine the class deriving from it.
The Subject (Observable) is a class and must be subclassed. So you run into the problem that you cannot subclass from another more important class. Java only allows single inheritance.
util. Observable is used to create subclasses that other parts of the program can observe. When an object of such subclass undergoes a change, observing classes are notified. The update( ) method is called when an observer is notified of a change.
Ans: The Observable class and the Observer interface have been deprecated in Java 9 because the event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications.
Class Observable. This class represents an observable object, or "data" in the model-view paradigm. It can be subclassed to represent an object that the application wants to have observed. An observable object can have one or more observers.
Quite simply it's a mistake that Observable is a class at all, abstract or otherwise.
Observable
should have been an interface and the JDK should have provided a convenient implementation (much like List
is an interface and ArrayList
is an implementation)
There are quite a few "mistakes" in java, including:
Arrays.toString(array)
as their default toString()
(how many SO questions has this caused?)Cloneable
shouldn't be a marker interface; it should have the clone()
method and Object.clone()
should not existWhile on the soapbox, in terms of the language itself, IMHO:
==
should execute the .equals()
method (this causes loads of headaches)==
should either be ===
like javascript or a dedicated method like boolean isIdentical(Object o)
, because you hardly ever need it!<
should execute compareTo(Object o) < 0
for Comparable
objects (and similarly for >
, <=
, >=
)As a first approach, one could think that this is done to allow the user to use composition instead of inheritance, which is very convenient if your class already inherits from another class, and you cannot inherit from Observable class also.
But if we look to the source code of Observable, we see that there is an internal flag
private boolean changed = false;
That is checked everytime the notifyObservers is invoked:
public void notifyObservers(Object arg) { Object[] arrLocal; synchronized (this) { if (!changed) return; arrLocal = obs.toArray(); clearChanged(); } for (int i = arrLocal.length-1; i>=0; i--) ((Observer)arrLocal[i]).update(this, arg); }
But from a class composed by this Observable, we cannot change this flag, since it is private, and the methods provided to change it are protected.
This means that the user is forced to subclass the Observable class, and I would say that the lack of the "abstract" keyword is just a "mistake".
I would say that this class is a complete screwup.
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