Map: Referenz oder Int-ID als key speichern?

[derkonstantin]

Hallo Community!

Ich möchte meine Frage mal an einem konkreten Beispiel erklären, damit es klarer wird, was ich meine:

Ich habe eine Personengruppe, in der ich die Attribute, die für jede Person (die der Personengruppe angehört) gespeichert werden soll, spezifiziere. Diese Attribut-Spezifikation findet in einer Liste von Objekten statt. Diese Object vom Typ AttributSpez speichern (vereinfacht gesagt) den Namen des Attributs (z. B. "Vorname", "Geburtsdatum" ...) und den Typ des Attributs (z. B. "String", "Datum" ...). Des Weiteren hat jedes Object AttributSpez eine eindeutige ID vom Typ int.

Nun möchte ich die Attribut-Werte in den Personen in einer Map speichern (welche genau, hab ich mir noch nicht überlegt; Empfelungen willkommen). Es muss nicht zwangsläufig zu jedem Attribut ein Wert bestehen.

Die Frage ist nun, ob ich als Key einfach das AttributSpez-Objekt nehmen kann/sollte (wenn ich das richtig sehe, wird ja eh "nur" die Referenz auf das Object gespechert und nicht das Objekt kopiert, richtig?) oder ob ich lieber die ID als Key nehmen soll (= Int-Value).

Ich hoffe, dass mein Anliegen verständlich ist. Andernfalls fragt bitte noch mal nach. Dann versuch ich das noch mal anders zu erklären.

Konstantin

 

[SlaterB]

das hängt davon ab, was du brauchst

wozu speicherst du denn die Elemente in einer Map?
wann greifst du auf die Map zu und was hast du dann zum suchen?
nur die Id oder das AttributSpez-Objekt?

wenn du das AttributSpez-Objekt hast, sind dann da nicht die benötigten Werte drin?,
wozu noch in die Map schauen, was ist da anderes drin?


in der Map kannst du übrigens kein int als Key ablegen,
es müsste ein Integer-Objekt sein

 

[derkonstantin]

wenn du das AttributSpez-Objekt hast, sind dann da nicht die benötigten Werte drin?,
wozu noch in die Map schauen, was ist da anderes drin?

Nein. Im AttributSpez-Objekt steht nur die Spezifikation drin (also id, bezeichnung und typ). (Da die Attribute der Personengruppe zur Laufzeit spezifiziert werden sollen, gibt es so ein AttributSpez-Objekt. Hier werden keine Werte gespeichert)
Eine Personengruppe hat n AttributSpez gespeichert und k Personen. Jede Person kann dann zu den AttributSpez der Personengruppen, denen sie angehört, einen bestimmten Wert speichern.

das hängt davon ab, was du brauchst

wozu speicherst du denn die Elemente in einer Map?
wann greifst du auf die Map zu und was hast du dann zum suchen?
nur die Id oder das AttributSpez-Objekt?

Nun möchte ich z. B. den Vornamen einer Person ändern. Das könnte ich entweder über die ID oder über das AttributSpez-Objekt realisieren.

in der Map kannst du übrigens kein int als Key ablegen,
es müsste ein Integer-Objekt sein

Stimmt, das hatte ich vergessen. Das wäre es wohl unsinnig ein zusätliches Integer-Objekt anzulegen, ne?

 

[SlaterB]

wenn es sich vermeiden läßt ja,
ob das so ist musst du wissen,

falls es noch weitergeht:
hat eine Personengruppe ein AttributSpez-Objekt und dann mehrere Personen mit Attributen?

auf was zeigt dann das eine AttributSpez-Objekt in der Map, falls es verwendet wird?
auf die Personengruppe oder die einzelnen Attribute? auf alle Attribute gleichzeitg?
häh??

 

[derkonstantin]

- 1 -

OK, ich gebe zu, dass mein Vorhaben ein wenig koplex ist. Ich bin auch schon einige Zeit dran, dieses zu modellieren.


Füllen wir das ganze mal mit Leben:

In dem Programm kann man beliebge Attribute spezifizieren. Beispiele: Vorname (einfacher String-Wert), Name (einfacher String-Wert), Geburtsdatum (einfacher Datums-Wert), Prüfernummer (zusammengetzer Wert aus Zahlen), Zeit für Anforderung XXY (irgendein anderer Typ) ...
Sagen wir mal, dieses wird duch eine Liste von Objekten einer (abstrakten) Klasse AttributSpez realisiert. So haben wir dann das Objekt vorname mit der id=1, bezeichnung="Vorname" und typ="Einfacher String-Wert" (Wobei "typ" hier als String vereinfacht dargestellt wird, um nicht zu sehr in die Tiefe zu gehen).

Nun legt man eine Personengruppe der Klasse "Personengruppe" an. Z. B. die Gruppe "Prüfer". Anschlißend kann man der Gruppe Attribute zusweisen. So soll z. B. zu jedem Prüfer der Vorname, Nachname und die Prüfernummer gespeichert werden.
Außerdem gibt es z. B. eine Gruppe "Teilnehmer" mit den Attributen Vorname, Nachname, Geburtsdatum und Zeit für Anforderung XYZ.


Die Gruppe Prüfer hat nun n Personen. Hier kann nun zu jedem Attribut ein Wert gespeichert werden (muss aber nicht, wenn nicht gesetzt). Also zum AttributSpez-Objekt vorname den Wert "Heinz" und so weiter ...
Analog zu den Teilnehmern.


Ist das Komzept an sich klar geworden? Die Frage ist, wie ich jetzt zu jedem Attribut die Werte speichere. Denke, dass eine Map der Form <AttributSpez, Wert> das Beste wäre. (Wie ich den Wert implementieren, weiß ich noch nicht genau. Wird auf Grund der Komplexität der möglichen Typen wohl eine abstrakte Klasse oder so ...)
In der Regel wird dann wohl aus der Klasse Personengruppe die Attribute-Spezifikationen der Reihe nach ausgelesen und anschließend zu jeder Person die Attributwerte erfragt, um eine Liste aller Personen der Personengruppe zu bekommen.



- 2 -

Wie implementiere ich am besten die Assoziation zwischen Personengruppe zu Person. Dieses soll beidseitig navigierbar sein (Ich möchte zum einem Wissen, welche Personen alle zur Personengruppe "Prüfer" gehören und zum zweiten möchte ich gern wissen, zu welchen Personengruppen die Person "Hans Meier" gehört.). Muss ich das rendundant speichern (Sowohl eine Liste in Personengruppe als auch eine Liste in Person)? Oder nimmt man da (wie bei relationalen DB) eine Hilfsklasse, welche die Assoziation speichert?

 

[byte]

Ich verstehe nicht, wo das Problem ist? Assoziationen sind einfache Referenzen. Mit irgendwelchen IDs musst Du eigentlich nicht hantieren. Definiere Dir erstmal eine Klasse Attribut, die könnte z.B. aus einem Schlüssel und einem Wert bestehen. Personen halten dann eine Liste mit Elementen vom Typ Attribut sowie eine Referenz auf die zugehörige Personengruppe. Personengruppe hält hingegen eine Liste mit den enthaltenen Personen. In dem Zusammenhang kannst Du Dir auchmal das Composite Entwurfsmuster angucken.

 

[derkonstantin]

Ich verstehe nicht, wo das Problem ist?

Das stimmt. ;-)

Assoziationen sind einfache Referenzen. Mit irgendwelchen IDs musst Du eigentlich nicht hantieren. Definiere Dir erstmal eine Klasse Attribut, die könnte z.B. aus einem Schlüssel und einem Wert bestehen. Personen halten dann eine Liste mit Elementen vom Typ Attribut

Na, so einfach ist das ja nicht. Aller Personen der Personengruppe A sollen ja bestimmte Attribute haben. Es dürfen also nur Personen der Personengruppe "Prüfer" das Attribut Prüfernummer haben. Also muss ja in der Klasse Personengruppe drin stehen, welche Attribute die Personen dieser Personengruppe haben. Und in der Klasse Person steht dann drin, welche Werte die Attribute haben.

Danke, ich werde das dann mit solch einer Map (wie oben beschrieben) realisieren. Die IDs werde ich wohl zum assoziieren wirklich nicht benötigen.

sowie eine Referenz auf die zugehörige Personengruppe. Personengruppe hält hingegen eine Liste mit den enthaltenen Personen. In dem Zusammenhang kannst Du Dir auchmal das Composite Entwurfsmuster angucken.

OK, also praktisch eine redundante Speicherung, bei der man aufpassen muss, dass es nicht zu Inkonsistenzen kommt. (Wobei wir hier keine Referenz auf die zugehörige Personengruppe haben, sondern eine Liste auf die zugehörigen Personengruppen!)

 

[byte]

Nein, keine redundante Speicherung. Die Objekte werden lediglich einmal im Heap abgelegt. Du setzt bloß an mehreren Stellen Referenzen auf die Objekte. Wo soll es da Deiner Meinung nach zu Inkonsistenzen kommen? Es gibt lediglich ein paar Anwendungsfälle, wo man bei solchen zyklischen Objektstrukturen aufpassen muss, z.B. beim Überschreiben von equals() oder der Implementierung von clone(). Wie gesagt, guck Dir einfach das Composite Pattern an.

 

[derkonstantin]

Ah jetzt weiß ich was du meinst.

Redundant meine ich nicht die Objekte an sich. (Es werden ja, wie du schon gesagt hast, nur die Referenzen gespeichert.)

Wenn nun aber in Personengruppe X steht, dass Person A zu dieser Personengruppe gehört, aber in Person A _nicht_ drin steht, dass diese zur Personengruppe X gehört, was ist dann richtig? Gehört sie nun zur Personengruppe X? Hier haben wir eine inkonsistenz. Oder sehe ich das falsch?

 

[byte]

Ach das meinst Du mit Inkonsistenz. Nun gut, Du musst natürlich gewährleisten, dass sowas nicht passieren kann. Aber wirklich schwierig ist das doch nicht. Du musst doch lediglich sicherstellen, dass jeweils beide Referenzen für diese bidirektionale Assoziation gesetzt werden.

Ich bin heute gut drauf und gebe Dir noch ein drittes Mal den Tipp, Dir das Composite Entwurfsmuster anzugucken. Das ist Deiner Problemstellung wie auf den Leib geschrieben. Nochmal werde ich das jetzt aber nicht mehr erwähnen.

 

[derkonstantin]

Ach das meinst Du mit Inkonsistenz. Nun gut, Du musst natürlich gewährleisten, dass sowas nicht passieren kann. Aber wirklich schwierig ist das doch nicht. Du musst doch lediglich sicherstellen, dass jeweils beide Referenzen für diese bidirektionale Assoziation gesetzt werden.

... und ggf richtig gelöscht wird. Aber das stimmt schon, es ist zu machen. ;-) Hätte mich halt nur interessiert, ob es veilleicht noch elleganter geht.

Ich bin heute gut drauf und gebe Dir noch ein drittes Mal den Tipp, Dir das Composite Entwurfsmuster anzugucken. Das ist Deiner Problemstellung wie auf den Leib geschrieben. Nochmal werde ich das jetzt aber nicht mehr erwähnen.

Entschuldige, dass ich da (noch) nicht drauf eingegangen bin. Ich hab das selbstverständlich gelesen und mir schon mal kurz angeguckt. Aber selbst nach näherem Betrachten sehe ich keinen Zusammenhang zur Personengruppe-Person-Assoziation. Auch sonst wüsste ich nicht, wo ich das im oben beschriebenen Problem einbauen sollte.

Ich habe im Wesentlichen die deutsche und englische Wikipedia-Seite zur Hilfe gezogen.
http://en.wikipedia.org/wiki/Composite_pattern
http://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)

Ich versuche das Verstandene mal in eigenen Worten zu fassen:
Es gibt eine abstrakte Oberklasse "Component", die das gemeinsame Verhalten von allen weiteren Klassen definiert.
Des Weiteren gibt es zwei Unterklassen, die davon abgeleitet sind. Eine, die Kindobjekte speichern kann (Composite) und eine, welche keine Kindobjekte speichern kann (Leaf).

Ein Composite-Objekt kann man sich also vorstellen, wie ein Ordner im Dateisystem. Er hat Methoden (und Attribute) wie eine normale Datei (umbenennen, verschieben, kopieren), kann aber wiederum Dateien als Kinder haben. Einfache Dateien (Leaf) haben nur die Methoden, ohne weitere Kind-Objekte.
Die abstrakte Oberklasse hat also die Methoden, die sowohl Dateien als auch Ordner haben.

Habe ich das so richtig verstanden? Meintest du das?


Die einzige Anwendung in meinem Beispiel würde ich bei der Attribut-Spezifikation sehen. Aber selbst da passt das nicht ganz. Ich werde mir aber da schon was zurecht stricken.


Trotzdem schon mal vielen Dank für deine Hilfe und Mühe.

 

[byte]

Deine Personengruppe ist ein Kompositum. Sie setzt sich aus Personen zusammen...