Jump to content

[Java] equals() / hashCode() auf Device-Ebene


Guest reto.koenig
 Share

Recommended Posts

Guest reto.koenig

Wäre es möglich die equals() und die hashCode() Methode noch (auf Device.java) zu implementieren?

 

Dann können die Devices auch in einem HashSet verwaltet werden.

 

Ich kann auch gerne dabei helfen... wie schon gesagt, ich hab's einfach nicht so mit github

 

Grüsse Reto

Link to comment
Share on other sites

Grundsätzlich sollte das bereits jetzt schon gehen oder? Wenn ich mich recht entsinne dann ist die Standardimplementierung von Object doch ein Referenzvergleich oder?

Das würde lediglich bedeuten, dass du Probleme bekommst, wenn du für die gleiche UID zwei Device-Objekte anlegst.

 

Ich würde behaupten, dass du dadurch auch von Seiten der TF-Bindings Probleme bekommst. Spätestens bei Verwendung zweier Devices mit gleicher UID in unterschiedlichen Threads können die Bindings für nichts mehr garantieren.

 

Oder übersehe ich gerade einen anderen Vorteil des Überschreibens von hashCode und equals? Ansonsten würde ich es vermutlich über die interne (int/long) UID implementieren.

Link to comment
Share on other sites

Guest reto.koenig

Ok, ich sehe, es kommt überhaupt nicht gut, wenn ein Device zweimal als Device-Objekt instanziert wird...

 

In der abstrakten Klasse Device.class wird beim Instanzieren eines Device-Objekt stets folgendes aufgerufen:

ipcon.devices.put(this.uid, this);

 

Da bringt es auch nix mehr, wenn man dann nachfragt, ob zwei Device-Objekte äquivalent sind... Denn das ältere Objekt ist aus dem Rennen... soz. zerstört.

 

Dann frage ich mich aber, ob es überhaupt erlaubt sein sollte, in einer JVM-Instanz ein Objekt zweimal als Device-Objekt instanzieren zu dürfen?

 

Link to comment
Share on other sites

Dann frage ich mich aber, ob es überhaupt erlaubt sein sollte...

 

Denke schon.

Sagen wir ich lege mir ein Device an, verliere dann alle Referenzen (das alte Objekt lebt aber noch wegen ausstehender GC) und möchte mir ein frisches Device zum Weiterarbeiten anlegen. Das würde jetzt schiefgehen. Dann bräuchte ich plötzlich einen expliziten Mechanismus zum Freigeben von Devices, um dieses neue Problem zu umgehen.

 

Ich denke dadurch wird das Fehlerpotenzial eher größer als kleiner.

 

Viele Grüße

Jan

Link to comment
Share on other sites

Guest reto.koenig

Nur ums schnell noch zu sagen: Ich jammere hier auf hohem Niveau. Das Framework an sich ist wirklich toll!

 

Bloss: Nachdem ich alle Referenzen verloren habe wäre es doch eigentlich gut sie wieder erlangen zu können, statt sie als 'side effect' dem GC dem Frass vorzuwerfen?!

Denn andere Teile des Programms arbeiten ja vielleicht noch mit dieser Instanz... So z.B. wenn sie sich als Listener bei dieser Instanz eingetragen hatten.

 

Der Ort, an dem diese Referenzen noch zu finden wären, um sie wieder aufzugreifen, ist die IPConnection. Dort gibt's die HashMap<Long,Device>, bei der ich per UID das Device wieder holen könnte. Aber diese Map ist mit Visibility: default/package  deklariert.

In dem Falle vielleicht ein

public Device getDevice(String uid)

in der IPConnection?

 

Ich möchte ja bloss, dass ich nicht unbemerkt eine an sich laufende Instanz 'abhänge', weil ich eine neue Instanz erzeuge...

 

Link to comment
Share on other sites

Naja... grundsätzlich bist du halt dafür verantwortlich die Referenzen die du selbst brauchst auch selbst zu behalten :D

 

Was ich geschrieben habe war eh unsinn. Erst wenn die IPConnection weg ist kommt der hungrige GC und isst alles auf. Weil solange hat die IPConn ja noch ne Referenz. Das ist auch gut so ^^

 

Ich halte es auf jeden Fall für vertretbar, dass man nur ein Objekt pro Stackelement haben darf.

Eine Methode zum Erlangen des Devices aus der IPConnection finde ich nicht vollkommen verwerflich, würde sie aber (wäre es mein Framework) nicht zur Verfügung stellen.

Wie ich als IPConnection meine Devices verwalte (z.B. dass ich sie problemlos per UID wiederfinden kann) würde ich verbergen.

Link to comment
Share on other sites

Guest reto.koenig

Gut! Bzgl. des 'Singleton' Ansatz sind wir uns klar einig, denn das sehe ich nun auch so.

 

Bloss, dass eine verlorengegangene Instanz nicht wieder zu beschaffen ist, das finde ich nicht so gut... (Memory-Leakage / Side-Effect).

 

In der IPConnection die HashTable private zu deklarieren finde ich natürlich auch klar gut.

 

Aber vielleicht wäre es wirklich nett, wenn die IPConnection die Referenz auf Anfrage (wie auch immer die dann aussieht) zurückgeben könnte?!

 

Ich schreibe mir nun mal einen Wrapper, der das Singleton-Verhalten der einzelnen Device-Instanzen für mich abbildet. Bloss.... ist ein wenig doppelspurig. Aber was sind schon ein paar 32bit-Referenzen Redundanz ;-)

 

 

Im übrigen: Danke für den konstruktiven Dialog mit mir als Novizen!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...