Beziehung 1-n in Java realisieren

[automatix]

Hallo!

Ich schreibe einen Bundesliga-Simulator und habe u.a. Klassen Spieltag (1) und Spiel (0..9), also eine 1-zu-n Beziehung. Wie sollte man das am besten umsetzen?

1. so:

class Spiel {
	Spieltag derSpieltag;
}
class Spieltag {
	
}

2. so:

class Spiel {
	
}
class Spieltag {
	Spiel[] dieSpiele;
}

3. so:

class Spiel {
	Spieltag derSpieltag;
}
class Spieltag {
	Spiel[] dieSpiele;
}

4. oder so:

class Spiel {
	
}
class Spieltag {
	
}
class AssoziationSpieleSpieltage {
	Object[][] spieleUndSpieltage;
}

?

Oder noch irgendwie?

Danke.

 

[maki]

Kommt darauf an wie du es brauchst

 

[automatix]

Mir geht es um das Design.

 

[maki]

>> Mir geht es um das Design.
lol

Schon klar, aber das Design richtet sich immer nach dem Verwendungszweck, es gibt kein gutes/richtiges Design ohne den Kontext zu beachten.

Willst du alle Spiele anhand der Spieltage ermitteln (2.), oder die Spieltage anhand des Spiels (1.), oder beides (3.)?

Bitte beachte das einfach 3. zu wählen ohne es zu brauchen die Sache unnötig Kompliziert machen würde, bidirektionale Assoziationen sind zu vermeiden wenn möglich.

Ansonsten sind Collections zu bevorzugen, Arrays sind so.. so "low level".

 

[tfa]

Du musst schon wissen, ob du Navigierbarkeit in beide oder in eine Richtung (und in welche) brauchst.

 

[automatix]

Es wird wohl jede der beiden Klassen die jeweils andere brauchen. Ein Spieltag, der nicht "weiß", welche Spiele zu ihm gehören, kann gar nichts, nicht mal sich vernünftig auf die Konsole schreiben. Aber manchmal müssen Spiele nach Spieltagen sortiert werden und dann brauchen sie die Informationen darüber, wann sie ausgetragen werden.

Mein Vorschlag Nr. 3 gefällt mir selber nicht -- ist einfach zu gefährlich bzw. aufwändig, denn bei jeder Veränderung auf einer Seite, muss geprüft werden, ob diese sich auf der anderen durchschlägt, damit das (Daten-)System konsistent bleibt.

Mit der 4. Variante bin ich auch irgendwie nicht zufrieden...

Was würdet Ihr vorschlagen? Gibt es eine Standard-Lösung für das Problem?

 

[maki]

Design fängt mit überlegen an, was brauche ich, wie brauche ich es?
Wenn du dir darüber im klaren bist, kanst du an das Design gehen, Unittests können helfen, sind aber für Anfänger oft verwirrend.

Mein Vorschlag Nr. 3 gefällt mir selber nicht -- ist einfach zu gefährlich bzw. aufwändig, denn bei jeder Veränderung auf einer Seite, muss geprüft werden, ob diese sich auf der anderen durchschlägt, damit das (Daten-)System konsistent bleibt.

Ja, wie gesagt, nicht optimal.
Wenn du es schon so machst, dann sorge gefälligst dafür dass beide Seiten in einer Methode eines Objektes gesetzt werden, vermeide redundanz, eine Seite der Beziehung muss dafür verantwortlich sein, entweder setzt Spiel den Spieltag bei sich selbst und bei Spieltag sich selbst,oder umgekehrt.


>> Was würdet Ihr vorschlagen? Gibt es eine Standard-Lösung für das Problem?

Lies doch nochmal meine & tfas Antwort...

 

[automatix]

>> Was würdet Ihr vorschlagen? Gibt es eine Standard-Lösung für das Problem?

Lies doch nochmal meine & tfas Antwort...

In Euren Antworten gehts darum, dass man erst wissen muss, was man mit seinen Klassen machen will, und erst dann an das Design geht. OK, das habe ich kapiert. Aber auf meine Frage, wie man das Problem am besten lösen sollte, geben die leider keine Antwort.

 

[ARadauer]

import java.util.ArrayList;


public class Spieltag {	
	ArrayList<Spiel> spiele;
	
	public Spieltag(){
		spiele = new ArrayList<Spiel>();
	}
	
	public void addSpiel(Spiel spiel){
		spiele.add(spiel);
		spiel.setSpieltag(this);
	}
}


public class Spiel {
	
	private Spieltag spieltag;

	public Spieltag getSpieltag() {
		return spieltag;
	}

	public void setSpieltag(Spieltag spieltag) {
		this.spieltag = spieltag;
	}
}

 

[automatix]

Das wird leider so nicht funktionieren (es sei denn man baut hier eine Überprüfung auf beiden Seiten ein, also in beiden Klassen und bei jedem Setter):

:Spiel.setSpieltagSpieltag) -- d.h. das Spiel weiß, dass es nicht mehr zum Spieltag X, sondern zum Spieltag Y gehört, aber weder der Spieltag X, noch der Spieltag Y haben das mitbekommen.

 

[maki]

In Euren Antworten gehts darum, dass man erst wissen muss, was man mit seinen Klassen machen will, und erst dann an das Design geht. OK, das habe ich kapiert. Aber auf meine Frage, wie man das Problem am besten lösen sollte, geben die leider keine Antwort.

Beste Lösung, Standard Lösung...

Das gibt es doch nicht, dachte das wäre mittlerweile klar?

Es kommt immer darauf an, wie man es benutzen will.

Das wird leider so nicht funktionieren (es sei denn man baut hier eine Überprüfung auf beiden Seiten ein, also in beiden Klassen und bei jedem Setter):

:Spiel.setSpieltagSpieltag) -- d.h. das Spiel weiß, dass es nicht mehr zum Spieltag X, sondern zum Spieltag Y gehört, aber weder der Spieltag X, noch der Spieltag Y haben das mitbekommen.

Verstehe leider nicht was du sagen willst?
Beispiel(code)?

 

[automatix]

In Euren Antworten gehts darum, dass man erst wissen muss, was man mit seinen Klassen machen will, und erst dann an das Design geht. OK, das habe ich kapiert. Aber auf meine Frage, wie man das Problem am besten lösen sollte, geben die leider keine Antwort.

Beste Lösung, Standard Lösung...

Das gibt es doch nicht, dachte das wäre mittlerweile klar?

Es kommt immer darauf an, wie man es benutzen will.

Ich dachte, wie ich es benutzen will, habe ich schon beschrieben. Oder?

Das wird leider so nicht funktionieren (es sei denn man baut hier eine Überprüfung auf beiden Seiten ein, also in beiden Klassen und bei jedem Setter):

:Spiel.setSpieltagSpieltag) -- d.h. das Spiel weiß, dass es nicht mehr zum Spieltag X, sondern zum Spieltag Y gehört, aber weder der Spieltag X, noch der Spieltag Y haben das mitbekommen.

Verstehe leider nicht was du sagen willst?
Beispiel(code)?

Bitte schön:

public class MyMain {
	
	public static void main(String[] args) {
		
		Spiel mySpiel01 = new Spiel();
		Spiel mySpiel02 = new Spiel();
		Spieltag mySpieltagA = new Spieltag();
		Spieltag mySpieltagB = new Spieltag();
		
		mySpiel01.setSpieltag(mySpieltagA); // Davon weiß aber mySpieltagA nix...
		// oder anders rum:
		mySpieltagB.addSpiel(mySpiel02); // Davon weiß aber mySpiel02 nix...
		
		/*
		dasgleiche Problem bei jeder anderen Veränderung,
		die sich auf die Spiel-Spieltag Beziehung auswirk
		*/
	}
	
}

// Nachtrag:

OK, die add()-Methode ist in Ordnung. Aber das Problem im Allgemeinen löst das trotzdem nicht.

 

[didjitalist]

Map<Spiel, Spieltag> spiele;

gut genug?

 

[ARadauer]

      mySpiel01.setSpieltag(mySpieltagA); // Davon weiß aber mySpieltagA nix... 
      // oder anders rum:

ja dann schreibst da halt noch was in die setSpieltag Methode, die das spiel in den tag einfügt und vielleicht vorher prüft ob er eh noch nicht drin ist..... je nach dem wie mans braucht...

 

[automatix]

      mySpiel01.setSpieltag(mySpieltagA); // Davon weiß aber mySpieltagA nix... 
      // oder anders rum:

ja dann schreibst da halt noch was in die setSpieltag Methode, die das spiel in den tag einfügt und vielleicht vorher prüft ob er eh noch nicht drin ist..... je nach dem wie mans braucht...

Ja, klar, nur ich dachte, vielleicht gibt es eine ganz andere Lösung, bei der dieses Inkonsistenz-Problem gar nicht erst auftreten kann. Gibt's aber offenbar nicht.

 

[maki]

Finde die Insel nicht besonders toll, gut geeignet für Anfänger, aber sonst nix.

 

[automatix]

Map<Spiel, Spieltag> spiele;

gut genug?

Naja, das ist eine verbesserte bzw. die eigentlich korrekte Version des "Vorschlag 4" oben. Würde funktionieren, warum nicht.

 

[Marco13]

Ein bißchen subjektiver Senf:

ARadauer hat schon beschrieben, wie man sicherstellen könnte, dass die Objekte sich gegenseitig kennen. (Wenn man die Methoden noch ein bißchen aufbohrt (und NUR die Methoden für Zuweisungen usw. verwendet) kann man auch sicherstellen, dass der Zustand immer(!) konsistent ist.

Die einzigen Argument, die dann noch dagegen sprechen würden, wären
1. Aufgeblähte API
2. Hoher Speicherverbrauch

Nr. 1 kann man ggf. vermeiden, indem man die Methoden, die nich unbedingt public sein müssen, package-private macht.
Nr. 2: Das ist der Tradeoff, den man SEHR oft hat. DU musst wissen, was in deinem Programm der use-case sein wird. Wird man häufiger (oder in zeitkritischeren Zusammenhängen)
- das Spiel fragen, an welchem Tag es stattfindet oder
- den Tag fragen, welche Spiele an ihm stattfinden?
Man kann natürlich auch nur EINE der beiden Richtugen explizit speichern, und die jeweils andere Information "on the fly" berechnen - sinngemäß:

Für deine ursprüngliche Variante 1 (Spiel kennt seinen Spieltag)

List<Spiel> getSpieleFürTag(Spieltag tag) 
{
    List result = ...
    for alle Spiele
    {
        if (spiel.getTag == tag) result.add(spiel)
    }
    return result
}

bzw. für deine ursprüngliche Variante 2 (Spieltag kennt seine Spiele)

Spieltag getTagVonSpiel(Spiet spiel) 
{
    for alle spieltage
    {
        if (spieltag.contains(spiel)) return spieltag
    }
}

Das kann natürlich zeitaufwändiger sein, wenn man z.B. eine Tabelle anzeigen will, und bei jeder Zelle irgendwelche langen Listen durchsuchen muss oder so.
Wenn du nicht gerade einen Datensatz mit allen weltweit jemals durchgeführten Spielen anlegen willst (wo es auf jedes byte ankäme) kann man vermutlich die "bequeme" Variante mit beiderseitgem Zugriff wählen....