[Java[ a->b b->a probleem

[Alarmnummer]

Stel dat ik 2 objecten A en B heb en ze moeten beiden van elkaar afweten. Dan deed ik altijd dit:

code:

class A 
{
   private B b = null;

   public void setB(B b){
    this.b = b;
   }
}

class B
{
   private A a = null;

   public void setA(A a){
    this.a = a;
   }
}

//koppelen
a.setB(b);
b.setA(a);

Maar laatst zag ik dit staan (geloof gegenereerd door Poseidon (UML Tool))

code:

class A
{
   private B b = null;

   public setB(B b){
    this.b = b;
    if(b.getA()==null)
       b.setA(this);
   }
}

En dan voor de B class hetzelfde en ben je klaar met de aanroep:

a.setB(b); of b.setA(a);

Het voordeel aan deze constructie is dat je nu niets fout kan doen. Je kan niet 1 link vergeten te maken zoals in het 1e voorbeeld. Maar A en B beginnen nu wel afhankelijker van elkaar te worden (voor zover ze dat nog niet waren). Mijn vraag is of jullie deze constructie ook gebruiken.

[PS] iedereen nog de beste wensen

[Scorpion]

code:

interface myInterface {
  public abstract void handle(Object data);
}

class B {

  myInterface handler;

  B(myInterface handler) {
    this.handler = handler;
  }
}

public class A implements myInterface {
  A() {
    b = new B(this);
  }

  public void handle(Object data) {
    // something...
  }
}

zoiets deed ik altijd...

[mbravenboer]

Het grote nadeel van deze 'oplossing' is het onverwachte side-effect van de methode setB(..). Als je deze oplossing kiest zo ik dus zeker een andere methode-naam nemen. Als iemand bijvoorbeeld eerst al een andere A had ingesteld, ben je flink de pineut.

Zelf los ik dit 'probleem' vaak op door het creeeren van een vrachtje objecten even standaard aan te bieden in een static medhode. Je kunt dan zelf dit vervelende gedoe afhandelen.

[Alarmnummer]

kun je hier een voorbeeldje van geven?

[.oisyn]

Op dinsdag 01 januari 2002 15:04 schreef mbravenboer het volgende:
Het grote nadeel van deze 'oplossing' is het onverwachte side-effect van de methode setB(..). Als je deze oplossing kiest zo ik dus zeker een andere methode-naam nemen. Als iemand bijvoorbeeld eerst al een andere A had ingesteld, ben je flink de pineut.

Dat kun je natuurlijk simpel oplossen door de check tegen null te vervangen door een check tegen this:

code:

if (b.getA () != this)
    b.setA (this);

Zelf los ik dit 'probleem' vaak op door het creeeren van een vrachtje objecten even standaard aan te bieden in een static medhode. Je kunt dan zelf dit vervelende gedoe afhandelen.

[Alarmnummer]

Op woensdag 02 januari 2002 03:34 schreef OiSyN het volgende:

Dat kun je natuurlijk simpel oplossen door de check tegen null te vervangen door een check tegen this:

code:

if (b.getA () != this)
    b.setA (this);

Dat had het ook moeten zijn mijn fout.

[mbravenboer]

Die null-check is inderdaad wel voor een deel een oplossing, maar toch vind ik nog steeds dat de methode een onverwachts effect heeft wat je moet terug zien in de methode naam...

Ik was wellicht een beetje vaag wat betreft mijn aanpak, beetje snel getikt . Het valt mij op dat deze situatie zich vaak voordoet bij initialisatie van applicaties. In gewone code komt het niet erg veel voor (en dat zou misschien ook niet moeten gebeuren). Vaak is het in mijn code ook zo dat je uiteindelijk geen directe referentie naar 1 van de twee objecten hoeft te hebben, maar dat de beide objecten weer 'verpakt' worden in een ander object. Door voor dat object even een default constructie mechanisme in een static methode te maken, hoef je je niet met zulke details bezig te houden...