Verfahren zum Erweitern einer Klasse mit privaten Konstruktoren

Question

Gibt es eine Standardtechnik zum "Erweitern" einer Klasse mit privaten Konstruktoren, wie bei den meisten Singleton-Klassen? Speziell versuche ich, die java.lang.management.ThreadInfo Klasse zu erweitern, weil ich eine Menge von ihnen zu einem HashSet hinzufüge, um Eindeutigkeit zu steuern. Die Art, wie ich feststelle, ob zwei Threads gleich sind, ist jedoch unterschiedlich und nicht identisch mit der Standardimplementierung der Methode equals().

Die Erweiterung der Klasse ist in diesem Fall offensichtlich keine Option.

Wäre es sinnvoll sein, so etwas wie eine Wrapper-Klasse zu machen, die ein ThreadInfo im Konstruktor übernimmt und dann auffüllt manuell alle relevanten Felder mit den Werten, dann überschreibt equals() und hashCode(), oder gibt es einen besseren Weg, dies zu tun?

So etwas ist, was ich zu schreiben fange, aber eine bessere Umsetzung wäre ideal:

class ThreadInfoWrapper { 

    private ThreadInfo info; 
    ThreadInfoWrapper(ThreadInfo info) { 
     this.info = info; 
    } 

    //Populate instance variables with Thread.State, thread ID, etc.. with 
    //Getters/setters and all that other stuff 

    public boolean equals(Object o) { //Unique implementation 
    } 

    public int hashCode() { //Whatever implementation 
    } 

} 

Aber das fühlt sich an wie ein sehr Umwege einige grundlegende Funktionalität zu erreichen. Ich habe es untersucht, und Implementierungen von Sets mit benutzerdefinierten Comparators sind in der Java-Standardbibliothek nicht vorhanden. Ich denke, ich könnte meine eigene Hash-Set-Implementierung schreiben, aber das ist zu viel Arbeit für eine einfache Situation. Alle Einsichten wären hilfreich.

Answer 1

Mit erweitert meinen Sie, wie abgeleitete Klassen erstellt werden, die den privaten Konstruktor als ihren Superklassenkonstruktor verwenden. Sie können nicht, sie wurden privat gemacht, um Sie daran zu hindern, das zu tun. Da die JRE-Klassen von kompetenten Programmierern geschrieben wurden, gibt es dafür gute Gründe. Selbst wenn Sie es mit Tricks, wie Reflektion oder Bytecode-Manipulation, umgehen könnten, sollten Sie dies nicht tun.

Aber alles ist nicht verloren. Sie sollten sowieso die Zusammensetzung der Vererbung vorziehen. Die Dekorator- und Proxy-Designmuster können nützlich sein (Ihr Beispiel liegt nahe bei diesen).

Answer 2

Ich denke, was Sie tun, ist vernünftig angesichts der Tatsache, dass es nur wenige andere Optionen gibt.

Eine Alternative könnte sein, Ihre eigene Unterklasse von HashMap zu schreiben, die Ihren "speziellen" equals anstelle des Standards verwendet. (Es kann bereits Apache oder Guave-Implementierungen sein, dies zu tun - jemand ohne Weiteres weiß)

(später hinzugefügt)

Weil ich bin faul, und weil Thread alle Getter hat, so ist es ziemlich „sicher“ zu entlarven , würde ich die Wrapper-Klasse zu machen sehr einfach, ohne Getter noch Setter versucht werden:

public class ThreadInfoWrapper { 

// public so an outsider can get at the wrapped ThreadInfo 
// could be private if you are sure that will never be necessary 
public final ThreadInfo threadInfo; 

public ThreadInfoWrapper(ThreadInfo threadInfo) { 
    this.threadInfo = threadInfo; 
} 

public boolean equals(Object o) { //Unique implementation 
    // refer to threadInfo.blah... 
} 

public int hashCode() { //Whatever implementation 
    // refer to threadInfo.blah... 
} 

}

Doch dies hängt davon ab, genau das, was Informationen, die Sie für Ihre Gleichen und hashcode verwenden.