Immutable Objects ?

[A3XX]

Hi

Also ich kenne Java ja doch schon einigermassen aber an der Uni nehmen die halt alles 10mal gründlicher durch als sonst

Also sind Immutable Objects nur Strings (so stehts zumindest bei uns) oder alle Objekte in Java?
Diese Eigenschaft is ja Java spezifisch und offenbar wird z.B. wenn man eine Variable überschreibt nur die Referenz auf ein Objekt in dieser Variable geändert. Das so quasi nun nicht mehr referenzierte Objekt ist damit nur noch Futter für den Garbage Collector. Das haben sie uns zumindest für die Strings gesagt.

Stimmt das auch bei den anderen?

 

[Guest]

(Fast)Alles aus java.lang ist Immutable, also String, Integer, Long, Double etc.
Es sind einfach ausgedrückt Objekte, die nach ihrer Erstellung keine weiteren
Änderungen zulassen.

z.B.

public ImmutableFoo
{
  private int i;

  public ImmutableFoo(int i)
  {
    this.i = i;
  }

  public int getI()
  {
    return this.i;
  }
  ...
}

Nachdem eine Instanz eines solchen Objektes erstellt ist,
kann man deren Attribute (hier nur int i) nicht mehr verändern,
da sie keine Setter-Methoden dafür bieten.

 

[Roar]

Immutable Objects sind (jaja, wir hättens nicht für möglich gehalten)
unveränderbare objekte. Strings sind unveränderbar. darum sind strings immutable objects :lol:
die meisten objekte sind allerdings veränderbar.. sonsz könnte man ja ganz OOP in die tonne hauen.
Andere unveränderbare objekter sind zum beispiel BigInteger und BigDecimal.
Der grundsinn:

Unveränderliche Klassen lassen sich leichter entwerfen, implementieren und nutzen als veränderliche Klassen. Sie sind weniger fehleranfällig und sicherer.

und dann sind da noch ne menge ausführungen blah blah blah.

 

[A3XX]

Also ihr schreibt jetzt ziemlich was unterschiedliches. Habt ihr irgendwelche Quellen auf die ihr euch bezieht? Ist jetzt eher viel Immutable oder nicht? ???:L

Und stimmt meine Erklärung, dass jeweils in einer Variable einfach die Referenz auf ein Objekt überschrieben wird und das nicht mehr referenzierte Objekt Garbage-Collector-Food ist?

Und welche Objekte sind dann Immutable?

 

[Roar]

hm? wieso ziemnlich unterschiedlich?
die meisten objekte sind nicht immutable, sonst gäbe es ja kaum sinnso zu programmieren. was hast du von einem Label wenn du nicht nachträglich den text ändern kannst?
und dass viele klassen in dem lang package unveränderbar sind is ja auch richtig...

das zitat von mir war aus dem buch Effective Java

 

[A3XX]

Hm dann kapier ich vielleicht die Definition nicht richtig?

So wie es uns übermittelt wurde, nehmen wir Dein Beispiel Label:

Wenn man ein Label erstellt, dann wird ein Objekt instanziert das den gewünschten Wert enthält. Wenn man den Wert ändert wird wie ein Objekt mit dem neuen Wert instanziert und die Referenz auf das Objekt an die alte Variable zurückgegeben, so dass man eigentlich von dieser Neuinstanzierung gar nichts gemerkt hat.

Stimmt das oder nicht?

 

[Roar]

Wenn man ein Label erstellt, dann wird ein Objekt instanziert das den gewünschten Wert enthält. Wenn man den Wert ändert wird wie ein Objekt mit dem neuen Wert instanziert und die Referenz auf das Objekt an die alte Variable zurückgegeben, so dass man eigentlich von dieser Neuinstanzierung gar nichts gemerkt hat.

öhm, das kapier ich irgendwie nicht. aber wenn ich Label.setText() aufrufe, wird nicht das ganze Label neu instantiiert, sondern nur dem feld "text" (oder wie auch immer blupp) ein neuer wert zugewiesen.
wenn jedesmal bei einer feldänderung das objekt neu instantiiert werden würde würde das ja in nem speicherchaos enden. und was ist wenn ich felder nicht im konstruktor festlege, sondern die erst später gesetzt werden können?

 

[Beni]

Wenn man ein Label erstellt, dann wird ein Objekt instanziert das den gewünschten Wert enthält. Wenn man den Wert ändert wird wie ein Objekt mit dem neuen Wert instanziert und die Referenz auf das Objekt an die alte Variable zurückgegeben, so dass man eigentlich von dieser Neuinstanzierung gar nichts gemerkt hat.

Stimmt das oder nicht?

Du kennst den Begriff "kreuzfalsch"? :bae:

Wenn du ein JLabel hast (das ist eine graphische Komponente die z.B. auf Fenstern angezeigt wird), kannst du die Eigenschaft "text" des Labels verändern, indem du label.setText( "halli Hallo" ); aufrufst.
Das Objekt, auf welches die Variable "label" zeigt, wird verändert (neuer Text), aber es wird kein neues JLabel-Objekt hergestellt.
JLabel ist mutable.

Ganz anders im Falle eines Stringes. Du kannst die Zeichenkette, welche von einem String dargestellt wird nicht verändern, du kannst nur ein neues String-Objekt herstellen.
String ist immutable.

Meine Kollegen hatten schon recht, als sie sagen, fast alle Klasse aus java.lang seien immutable. Aber sie haben nicht erwähnt, dass diese Klassen nicht mehr als 1% aller Klassen der JRE sind :wink:

 

[Guest]

Das Adjektiv 'imutable' (engl. unveränderbar) beschreibt einfach, dass ein Objekt
die Änderung seines inneren Zustands nicht zulässt.

Es heisst nicht, dass eine 'Variable', die eine Referenz eines solchen Objektes
enthält, unveränderbar ist. Dies ist eine andere Geschichte.
Wenn ein Objekt nicht mehr referenziert wird, oder wenn das Objekt von einem anderen
referenziert wird, welches nicht mehr nicht mehr referenziert wird, dann wird es früher oder
später vom GC freigegeben.