Bidirektionale 1:1 Assoziation

[mrbela]

Hey Leute!

Ich habe folgenden Fall, den ich gerne in Java darstellen möchte:

Es gibt eine Person, die hat ein Auto. Und ein Auto, das einen Eigentümer hat. Also eine klassische 1:1 Assoziation. Nun die Frage wie ich das implementiere... Ich muss ja beachten, dass ein Auto keinen zwei Personen (= Eigentümer) zugewiesen werden kann, also z.B.:

Auto a = new Auto(...);
Person p1 = new Person(...);
Person p2 = new Person(...);

p1.auto = a;
p2. auto = a;

und umgekehrt: Keiner Person zwei Autos.

Jetzt hab ich mich mal schlau gemacht und habe gelesen, dass man dies über die setter-Methode regulieren muss.

Mein Ansatz:

In der Klasse Person:

	public void setAuto(Auto auto) {
		this.auto = auto;
		auto.setEigentuemer(this);
	}

und in der Klasse Auto:

	public void setEigentuemer(Person p) {
		this.eigentuemer = p;
		p.setAuto(this);
	}

So müsste es doch passen, oder??

Danke für Eure Hilfe!

Edit: Das produziert eine Endlosschleife, sehe ich gerade...

 

[mrbela]

Hatte eben nciht viel nachgedacht. Das gibt natürlich eine Enlosschleife.

Daher jetzt mein Ansatz:

In der Klasse Person:

	public void setAuto(Auto auto) {
		this.auto = auto;

		if (auto.getEigentuemer() != null) {
			if (!auto.getEigentuemer().equals(this)) {

				auto.setEigentuemer(this);
			}
		}
	}

In der Klasse Auto:

	public void setEigentuemer(Person p) {
		this.eigentuemer = p;

		if (p.getAuto() != null) {
			if (!p.getAuto().equals(this)) {

				p.setAuto(this);
			}
		}
	}

Was meint ihr dazu?

 

[tschero]

Du kannst auch in der Klasse Auto ein Objekt Person als "final" deklarieren.

private final Person myEigentuemer = new person();

Somit hat das Auto einen unveränderlichen Eigentümer vom Typ Person.

Gruß
tschero

 

[tröööt]

und umgekehrt: Keiner Person zwei Autos.

und wieso nicht wenn man fragen darf ? eine person kann doch eine beliebige anzahl an eigenen fahrzeugen haben ... nur das ein auto mehrere eigentümer hat haut so meist nicht ganz hin ... also nix mit klassich 1:1 ...
außerdem sollte "Eigentümer" abstrakt sein ... denn nicht nur eine natürlich person kann ein auto sein eigentum nennen ... sondern auch jede juristische instanz (firma) kann ein auto besitzen ... wobei es hier dann deutlich wird : eine firma hat meist mehr als nur genau einen firmenwagen ... und spätestens damit wäre deine aussage widerlegt ...

auch andere eigenschaften eines autos wie fahrer sind eindeutig ... nur eventuelle "gesamtinsassen" oder "beifahrer" können variieren ...

 

[Spacerat]

Also den Besitzer in der Autoklasse final machen ist hier die schlechteste aller Ideen und hat im Prinzip auch nichts mit dem Problem zu tun.
Also: Es gibt Personen und Autos. Ein Auto kann nur von einer Person (Fraktion oder was auch immer) besessen werden, eine Person darf aber mehrere Autos besitzen. Ferner darf sich eine Person neue Autos hinzu- und Autos im Besitz verkaufen (Der Grund, warum final so fatal ist).
Ganz banal wäre also in der Klasse Person ein Set<Auto> zu definieren und in der Klasse Auto entsprechend einen Member Person. Diese könnte man mit Gettern, Settern, Addern und Removern verwalten.

class Person {
  private final Set<Auto> myCars = new HashSet<Auto>();

  public void addCar(Auto car) {
    Person owner = car.getOwner();
    if(owner != null) {
      owner.removeCar(car);
    }
    myCars.add(car);
    car.setOwner(this);
  }

  public void removeCar(Auto car) {
    myCars.remove(car);
    car.setOwner(null);
  }
}

class Auto {
  private Person owner;

  public Person getOwner() {
    return owner;
  }

  public void setOwner(Person owner) {
    if(owner != null && this.owner != null) {
      throw new IllegalStateException();
    }
    this.owner = owner;
  }
}

...wenn es nun von der Aufgabe her so sein mag, dass eine Person nur ein Auto besitzen darf, dann ändert man die Assoziationsbedingungen in dieser Klasse eben dahingehend ab, dass sie jenen der Klasse Auto entsprechen. Zumindest müssen die Abhängigkeiten stets beiderseitig erfragt werden können, deswegen heisst's auch bidirektionale Assoziation.