Referenzen - 2ter Versuch

[kit fisto]

Okay, ich mache einfach nen neuen Thread auf in dem ich das eigentliche Problem nochmal deutlicher mache:

List liste1 = new List();
String out1 = "";
String out2 = "";
for(int i=0;i<5;i++)
{
  liste1.insertBehind(""+i);
}

List liste2 = liste1;

liste1.toFirst();
liste2.toFirst();

while(!liste2.isBehind())
{
  out2 = out2 + (String)liste2.getItem();
  liste2.next();
}
while(!liste1.isBehind())
{
  out1 = out1 + (String)liste1.getItem();
}
System.out.println("neue Liste: "+out1);
System.out.println("alte Liste: "+out2);

Wer die Klasse list hat so wie sie für's Abitur vorgegeben wird, kanns ja mal testen. Was man sehen wird ist, dass die Ausgabe der "Neuen Liste" vollständig gelingt. Die Ausgabe der "alten Liste" ist jedoch leer. Dies liegt daran das list1 und list2 auf dasselbe Objekt verweisen - klare Sache.

Bei folgendem Programm hab ich vermutet das es sich genauso verhält:

public void fuegeHinzu(Ahne pAhne, String pLinie) {
  BinTree lBaum = hatAhnenbaum;
  while (pLinie.length() > 1) {
    if (pLinie.charAt(0) == 'm') {
      lBaum = lBaum.getLeftTree();
   }
   else {
     if (pLinie.charAt(0) == 'v') {
       lBaum = lBaum.getRightTree();
     }
   } // if else
   pLinie = pLinie.substring(1);
  } // while
  BinTree lNeuBlatt = new BinTree(pAhne);
  if ((pLinie.charAt(0) == 'm') {
    lBaum.setLeftTree(lNeuBlatt);
  }
  else {
    if ((pLinie.charAt(0) == 'v') {
      lBaum.setRightTree(lNeuBlatt);
    }
  } // if else
}

Hier sollten "hatAhnenBaum" und "lBaum" auf das gleiche Objekt verweisen oder? Ist aber scheinbar nicht so, denn wenn man sich mal "lBaum" und "hatAhnenBaum" ausgeben lässt, sieht man das "lBaum" nur aus einer Wurzel und einem Nachfolger (Blatt) besteht während "hatAhnenBaum" ein ganzer Ahnenbaum inklusive des neu hinzugefügten Element...

Warum ist dies so???? Sind nicht "hatAhnenBaum" und "lBaum" einfach Referenzen auf ein und dasselbe Objekt der Klasse BinTree ebenso wie "liste1" und "liste2" Referenzen auf ein und dasselber Objekt der Klasse List sind!?

Wo ist mein Denkfehler bzw die Erklärung für den Unterschied!?

Lg, kit fisto!

 

[SlaterB]

> denn wenn man sich mal "lBaum" und "hatAhnenBaum" ausgeben lässt
wann und wo machst du das?

lBaum ist anfangs gleich hatAhnenbaum, aber in Zeile 5 und 9 werden doch wieder ganz andere Bäume zugewiesen,
am Ende ist lBaum nicht ein Minibaum, dafür sogar ja gerade die große while-Schleife

 

[eRaaaa]

Hier sollten "hatAhnenBaum" und "lBaum" auf das gleiche Objekt verweisen oder?

Zumindestens nach Zeile2 denke ich schon ja

Ist aber scheinbar nicht so, denn wenn man sich mal "lBaum" und "hatAhnenBaum" ausgeben lässt, sieht man das "lBaum" nur aus einer Wurzel und einem Nachfolger (Blatt) besteht während "hatAhnenBaum" ein ganzer Ahnenbaum inklusive des neu hinzugefügten Element...

Naja, ich blicke zwar noch nicht ganz durch, aber du veränderst doch unter Umständen die Referenz von lBaum (Zeile5 und 9) ?? Dann zeigt lBaum ja nicht mehr aufs selbe Objekt....

 

[kit fisto]

Die Ausgabe erfolgt in dem Ausschnitt niergends Das ist einfach eine Behauptung meinerseits die ich aber gegebenenfalls durch den Programmcode der Ausgabe noch bestätigen kann wenn ich wollt^^

eRaaaa du hast genau erkannt wo mein Problem ist glaube ich! lBaum wird verändert und ist am Ende ein ganz kleiner Baum an den in Zeile 16 & 20 ein neuer Teilbaum angehängt wird!

Wie kommt es nun dazu, dass wenn man hatAhnenBaum ausgibt, dieser neue Teilbaum, der an lBaum angefügt wurde, auch hier genau an der Stelle von lBaum auftaucht!?

 

[SlaterB]

wieso nicht?
wenn in eine Liste 5 Elemente drin sind und das Element 3 davon verändert wird und die Liste danach ausgegeben, dann zeigt sie auch das geänderte Element 3 an,

hier ist es ein Baum, der in einem unteren Teil verändert wird,
andere Variablen können ruhig auch auf den Baum oder einen der Unterknoten zeigen und darin was ändern,
da wird nicht automatisch ein neuer Baum erzeugt,

ein Teilbaum ist auch immer ein Baum, lBaum enthält keinen eigenen neuen Baum sondern einen Unterknoten des Hauptbaumes

 

[kit fisto]

hört sich ja so ziemlich banal an^^
Dieses Listenbeispiel wurde in der als sinnlos bewertet weil niemand eine solche konstruktion gebrauchen würde... Zwei Referenzen auf ein Objekt wären sinnlos^^ Aber beim Baum scheints ja notwendig zu sein?

[edit]
Naja das verändern bzw hinzufügen von Elementen in einen Baum ist ja ein wenig komplizierter als bei der Liste. und um die gewünschte stelle im baum zu finden muss man die die jeweiligen teilbäume ausgeben lassen... ist die stelle gefunden, wird an diesen teilbaum, der ja in meinem Beispiel lBaum ist, eingefügt. zu dem Zeitpunkt ist lBaum aber schon nicht mehr der große baum, sondern ein kleiner teilbaum... wo ist jetzt die beziehung vom kleinen zum großen teilbaum....

Und das funzt ja zB bei integern nicht:
a=1
b=a
b++; dann ist b=2 und a=1^^

 

[SlaterB]

zwei Referenzen sind beim Baum nicht sinnvoller als bei der Liste,
nur sieht es dort so aus als wären es zwei, zum Durchhangeln für die while-Schleife,

und die Referenz lBaum hat den gleichen Typ wie der Ursprungsbaum, das ergibt sich durch die Datenstruktur, hat aber für sich keine höhere Bedeutung,

die Liste ist an sich ein sehr gutes Vergleichsbeispiel

List l = ..            <->        Baum b = ..
Object o = l.get(i)    <->        Baum c = b; c = c.getLeft();
o.change();            <->        c.change();

->
l enthält verändertes o <->      Baum b enthält veränderte Unterelemente

--------

Und das funzt ja zB bei integern nicht:
a=1
b=a
b++; dann ist b=2 und a=1^^

immer das Zuweisen vom Verändern unterscheiden,
würde man der lBaum Variablen (oder in meinem Vergleichsbeispiel oben o und c) ein neues Objekt zuweisen, so würde das den Baum bzw. die Liste auch nicht kratzen,

x = ..;
ist immer was anderes als
x.changeIntern();

 

[function]

wegen deinem baum, wenn ich das so richtig sehe setzt am Anfang lBaum und ahnenbaum gleich nur um einen "Startpunkt" zu geben. Im weiteren Programm verlauf wird lBaum immer durch einen Teilbaum, von sich selbst, ersetzt...
Wenn du schließlich an ein Blatt hinzufügst, fügst du einem Objekt Blatt(typ BinTree) einen weiteren BinTree hinzu, dadurch veränderst du das Objekt(intern) an der Stellen, das sowohl im ahnenbaum, also auch im lBaum die gleiche referenz besitzt, darum werden änderungen überall übernommen...

hoffe es wird klar was ich meinen

 

[kit fisto]

und wieso ist das jetzt so.... Ich sehe immernoch nicht warum das beim baum so ist... tut mir leid oO
was meinst du mit "das ergibt sich durch die Datenstruktur"??

 

[kit fisto]

okay das hab ich glaub ich verstanden...
Ich möchte euch kurz erklären das ich in ca 3 oder 4 Wochen Abitur mache und meine LK-Lehrerin nicht im Stande ist mir eine solche Erklärung zu liefern. Und das mit der Liste war ihr vollkommen unbekannt... Danke euch!!!

 

[SlaterB]

> und wieso ist das jetzt so....
was genau?

'das ergibt sich durch die Datenstruktur' hatte ich zu 'die Referenz lBaum hat den gleichen Typ wie der Ursprungsbaum' geschrieben,
meinst du wirklich das?

so ist das eben bei rekursiven Datenstrukturen wie einen Baum,
dort kann man nicht sagen oben Baum, darunter Unterbaum, denn was kommt unter dem Unterbaum, ein Unterunterbaum?
jeder Teilbaum ist für sich selber ein vollständiger Baum, kann aber Teil eines anderen Baums sein,

warum? gut, das wird philosophisch, aber ohne diese Eigenschaft hätte man keine saubere beliebig erweiterbare Datenstruktur

 

[kit fisto]

Also ich merke schon Baum sollte man nur rekursiv bearbeiten^^ Das ist logischer
als dieser iterative Ansatz Also nochmal als zusammenfassung:
lBaum und hatAhnenBaum sind zunächst das gleiche. lBaum wird aber dann immer wieder zu seinen eigenen Teilbäumen die auch an gleicher Stelle in hatAhnenbaum vorhanden sind. Wird ein Element (lBaum) geändert, so wird es auch in hatAhnenBaum geändert, weil lBaum immernoch ein Element aus hatAhnenBaum ist!? Soweit richtig???

 

[SlaterB]

in etwa

 

[function]

so kann man das inetwa ausdrücken

 

[kit fisto]

hm in etwa scheint ja nicht ganz 100% den kern getroffen zu haben... was hab ich vergessen bzw noch nicht ganz verstanden oO...

 

[SlaterB]

wenn du es so genau nimmst:

> die auch an gleicher Stelle in hatAhnenbaum vorhanden sind
-> welche gleiche Stelle? lBaum ist für sich ein Baum, da gibts keine Stelle, lBaum hat aber im Ahnenbaum eine gewisse Stelle,
so wie ein Objekt o in einer Liste eine gewisse Position hat, Index 4 oder 7, aber man würde nicht von 'gleicher Position' sprechen

> weil lBaum immernoch ein Element aus hatAhnenBaum ist
fand ich zunächst noch mehr 'in etwaiger', aber ist wohl doch eine korrekte Bezeichnung

 

[Michael...]

Variablen sind keine Objekte sondern referenzieren auf diese.
Zu Beginn zeigen sowohl lBaum als auch hatAhnenBaum auf das selbe Objekt.
In der while Schleife "wandert" lBaum - anhand der in pLinie definierten Regeln - durch die Baumstruktur und zeigt am Ende auf einen Knoten innerhalb der Baumstruktur
Dann wird an den Knoten auf den lBaum zeigt etwas verändert. Dieser Knoten ist aber immer noch Bestandteil der selben Baumstruktur zu dem auch der (hierarchisch höher angesiedelte) Knoten gehört auf den hatAhnenBaum referenziert.

 

[function]

> weil lBaum immernoch ein Element aus hatAhnenBaum ist
fand ich zunächst noch mehr 'in etwaiger', aber ist wohl doch eine korrekte Bezeichnung

Da sehe ich auch die Schwierigkeit in der Beschreibung, weil der AhnenBaum selbst nicht weiß wie tief/groß er ist. Er weiß, dass er ein Knoten mit 0, 1, oder 2 "Blättern" ist. Tiefergehende Strukturen kennt der AhnenBaum nicht, seine "Blätter" können echte Blätter sein, aber auch weitere Bäume...
Ich will dich nicht groß verwirren,deshalb
Deine Aussage, dass ein Element eines "Unterbaums"(lBaum) immer ein Element des AhnenBaums ist, ist eine Zwangsbeziehung der Konstruktion...