Referenizierung beiderseits

[seejay]

Hallo,
wenn ich 2 Klassen habe, bestellung und user. Und ein User mehrere Bestellungen und eine Bestellung mehrere User haben kann, wie sollte ich es dann in den Klassen machen. Sollte ich in beiden Klassen eine Variable haben:

class bestellung
ArrayList<user>....

class user
ArrayList<bestellung>...

oder sollte ich es nur in einer von beiden Speicher. Dies hat doch Problem der Suche in umgekehrter Reihenfolge

oder sollte ich es gar nicht speichern und bei nachfrage raussuchen. Also eine Methode in beiden Klassen, die bei Nachfrage die Daten aus der DB temporär läd. Hier sind es doch dann aber zuviele Abfragen, wenn zu einer Bestellung viele Anfragen kommen.

Nach meinen Gedanken im Moment bleibt nur Variante 1, ist dies aber richtig und auch guter Stil?

Gruß
seejay[/code]

 

[SnooP]

Das kommt darauf an... grundsätzlich sollte man immer nur so viel Navigation und Referenzen zulassen, wie man gerade braucht. Das heißt erst in die eine Richtung mache und wenn man dann später merkt, damit kommt man nich aus, nimmt man die andere bidirektionale Referenz noch dazu...

handlen musst du das natürlich dann trotzdem - sprich, wenn du ein Bestellung für einen User erstellst, musst du die Referenz nicht nur in der ArrayList zum User hinzufügen, sondern auch in dem Bestellobjekt... wobei ich es jetzt momentan etwas seltsam finde, dass ein und dieselbe Bestellung von mehreren Usern getätigt werden kann? ich hätte da eine n:1 Beziehung erwartet.

 

[seejay]

Das kommt darauf an... grundsätzlich sollte man immer nur so viel Navigation und Referenzen zulassen, wie man gerade braucht. Das heißt erst in die eine Richtung mache und wenn man dann später merkt, damit kommt man nich aus, nimmt man die andere bidirektionale Referenz noch dazu...

Später im Sinne von Programmieren oder später im Sinne von während dem Programm, also zuerst keine Referenz laden und erst bei Anfrage.

handlen musst du das natürlich dann trotzdem - sprich, wenn du ein Bestellung für einen User erstellst, musst du die Referenz nicht nur in der ArrayList zum User hinzufügen, sondern auch in dem Bestellobjekt... wobei ich es jetzt momentan etwas seltsam finde, dass ein und dieselbe Bestellung von mehreren Usern getätigt werden kann? ich hätte da eine n:1 Beziehung erwartet.

z.b. Sammelbestellungen, einer bestellt für viele und dass er weiß für wen er alles bestellt hat könnte er es eintragen.

 

[SnooP]

Später im Sinne von Programmieren... - Referenzen kann man nicht zur Laufzeit hinzufügen... also Objekte natürlich schonn... aber die Felder natürlich nich

 

[Guest]

ich würde es als zwei static hashmaps in einer separaten klasse (evtl ein singleton) auflösen:

mapUser<User,Order>  
mapOrder<Order,User>

 

[happy_robot]

ich würde es als zwei static hashmaps in einer separaten klasse (evtl ein singleton) auflösen:

mapUser<User,Order>  
mapOrder<Order,User>

ACK

 

[seejay]

ah stimmt, des is ne gute idee und dann darin auch die Methode fürs prüfen
aber freundeslisten sollte man eher in die Klasse User packen oder, also die Liste mit allen Freunden des einen Users? Wobei duch Hashmaps wären durchsuchungen durch mehrere ebenen leichter

 

[SnooP]

Find ich ist ne blöde Lösung

ich würde beide Referenzen machen und entsprechende Hilfsmethoden bauen, sprich z.B. so

   user.addBestellung(Bestellung b) {
      this.bestellungen.add(b);
      b.addUser(this);
   }

static maps für solche Beziehungen find ich unschön.

 

[Marco13]

Mal ganz allgemein: Die Frage sollte unwichtig sein. Der Benutzer sollte eine Methode haben 'getBestellungen', und die Bestellungen sollten eine Methode haben 'getBenutzer'. Die sind dann "irgendwie" implementiert. HashMap, Array, zwei Arrays, ArrayListen, .... egal. Und wenn man dann das ganze laufen läßt, und merkt: "Hey, für die Benutzer die Bestellungen raussuchen dauert ja ewig!" dann erstellt man im Benutzer eine ArrayList, die die Bestellungen speichert, und gibt die dann in der getBestellungen-Methode zurück.

 

[happy_robot]

static maps für solche Beziehungen find ich unschön.

es entkoppelt aber die bestellung gänzlich vom user und umgekehrt.

daher finde ich das extrem schön

 

[ms]

static maps für solche Beziehungen find ich unschön.

es entkoppelt aber die bestellung gänzlich vom user und umgekehrt.

daher finde ich das extrem schön

Und in welcher Klasse sitzen diese static Maps?

ms

 

[happy_robot]

static maps für solche Beziehungen find ich unschön.

es entkoppelt aber die bestellung gänzlich vom user und umgekehrt.

daher finde ich das extrem schön

Und in welcher Klasse sitzen diese static Maps?

ms

in einer weiteren klasse die diese zuordnung herstellt (evtl ein singleton). dies könnte man auch als proxy realisieren die dann bei bedarf die daten liest. zum schreiben, evtl in eine db, wäre es auch imho ein eleganter und eindeutiger weg.

in einer datenbank müssten man es ja dann auch über eine relation auflösen (n:n). warum sollte man dann nicht auch schon in der implementierung eine eigenständige klasse bauen die dieses zentral erledigt.

 

[mu]

ich würde es als zwei static hashmaps in einer separaten klasse (evtl ein singleton) auflösen:

mapUser<User,Order>  
mapOrder<Order,User>

ACK

http://de.wikipedia.org/wiki/ACK

 

[masta // thomas]

Meinst du Arbeitsgemeinschaft Christlicher Kirchen?

(konnt ich mir nicht verkneifen )

 

[ms]

static maps für solche Beziehungen find ich unschön.

es entkoppelt aber die bestellung gänzlich vom user und umgekehrt.

daher finde ich das extrem schön

Und in welcher Klasse sitzen diese static Maps?

ms

in einer weiteren klasse die diese zuordnung herstellt (evtl ein singleton). dies könnte man auch als proxy realisieren die dann bei bedarf die daten liest. zum schreiben, evtl in eine db, wäre es auch imho ein eleganter und eindeutiger weg.

in einer datenbank müssten man es ja dann auch über eine relation auflösen (n:n). warum sollte man dann nicht auch schon in der implementierung eine eigenständige klasse bauen die dieses zentral erledigt.

Genau darauf wollte ich hinaus.
Deinen static-Ansatz kann ich allerdings nicht ganz nachvollziehen.
Wenn es um Relationen geht, dann hilft dir eine static Map nichts. Eine static-Map wäre doch in diesem Fall nur ein Hilfskonstrukt zum indizieren.

ms

 

[happy_robot]

Deinen static-Ansatz kann ich allerdings nicht ganz nachvollziehen.
Wenn es um Relationen geht, dann hilft dir eine static Map nichts. Eine static-Map wäre doch in diesem Fall nur ein Hilfskonstrukt zum indizieren.

es ist imho eine elegante, zentrale, nicht redundante und transparente lösung die zwei klassen entkoppelt. grosse philosophische ansätze habe ich jetzt da nicht verfolgt.
ich würde es jederzeit einer internen klassen-implementierung vorziehen.

 

[happy_robot]

Deinen static-Ansatz kann ich allerdings nicht ganz nachvollziehen.
Wenn es um Relationen geht, dann hilft dir eine static Map nichts. Eine static-Map wäre doch in diesem Fall nur ein Hilfskonstrukt zum indizieren.

es ist imho eine elegante, zentrale, nicht redundante und transparente lösung die zwei klassen entkoppelt. grosse philosophische ansätze habe ich jetzt da nicht verfolgt.
ich würde es jederzeit einer internen klassen-implementierung vorziehen.
und ob das nun static ist oder nicht wäre mir auch fast wurscht. ich sehe aber keine notwendigkeit für mehrere instanzen.

ouuppss...doppelpost.....keine ahnung wie das jetzt passiert ist....sorry