Pourquoi java.util.Observable n'est pas une classe abstraite ?

Question

Je viens de remarquer que java.util.Observable est une classe concrète. Puisque le but d'Observable est d'être étendu, cela me semble plutôt étrange. Y a-t-il une raison pour laquelle elle a été implémentée de cette façon ?

J'ai trouvé cet article qui dit que

L'observable est une classe concrète, donc la classe qui en dérive doit être déterminée au préalable, car Java ne permet qu'un seul héritage.

Mais ça ne l'explique pas vraiment pour moi. En effet, si Observable était abstrait, l'utilisateur serait obligé de déterminer la classe qui en dérive.

Answer 1

Il s'agit tout simplement d'un erreur que Observable est une classe du tout , abstraites ou non.

Observable aurait dû être un interface et le JDK aurait dû fournir une implémentation pratique (un peu comme List est une interface et ArrayList est une mise en œuvre)

Il y a pas mal d'"erreurs" en java, notamment :

• java.util.Stack est une classe, pas une interface (comme Observable, mauvais choix)
• java.util.Properties étend java.util.Hashtable (plutôt que utilise un)
• El java.util.Date est un peu désordonné, et est pas immuable ¡!
• El java.util.Calendar est une classe réel désordre
• Pas de type 'byte' non signé (c'est un vrai problème et la source de nombreux bogues de bas niveau).
• java.sql.SQLException es un vérifié exception
• Les tableaux n'utilisent pas Arrays.toString(array) par défaut toString() (combien de questions sur les SO cela a-t-il provoqué ?)
• Cloneable ne devrait pas être une interface de marqueur ; elle devrait avoir l'attribut clone() et Object.clone() devrait pas existe

Alors que sur le boîte à savon en termes de la langue elle-même, IMHO :

• == devrait exécuter le .equals() (ce qui cause de nombreux maux de tête)
• comparaison des identités == devrait être soit === comme javascript ou une méthode dédiée comme boolean isIdentical(Object o) parce que vous n'en avez presque jamais besoin !
• < devrait exécuter compareTo(Object o) < 0 para Comparable (et de même pour les objets > , <= , >= )

Answer 2

En première approche, on pourrait penser que cela est fait pour permettre à l'utilisateur d'utiliser la composition au lieu de l'héritage, ce qui est très pratique si votre classe hérite déjà d'une autre classe et vous ne pouvez pas non plus hériter de la classe Observable.

Mais si nous regardons le code source de Observable, nous voyons qu'il y a un drapeau interne

private boolean changed = false;

Elle est vérifiée à chaque fois que la fonction notifyObservers est invoquée :

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);
    }

Pero d'une classe composée par cet Observable, nous ne pouvons pas changer cet indicateur puisqu'il est privé et que les méthodes fournies pour le modifier sont protégées.

Cela signifie que l'utilisateur est obligé de sous-classer la classe Observable, et je dirais que l'absence du mot-clé "abstract" est juste une "erreur".

Je dirais que cette classe est un échec total.