Boolean, Double ... nicht änderbar

Warum kann man eigentlich bei Boolean, Double usw. Klassen den Wert nachträglich nicht mehr ändern? Sind die nur dazu da, um primitive Typen in Listen usw. zu packen? Gibts dann garkeine Möglichkeit von einer Methode noch etwas zurück zu bekommen auser den Rückgabewert?

nep

Nein die kannst du nicht ändern, das sind sog. "Immutables", d.h. unveränderbare Objekte.

Warum macht man das ?
Naja dadurch ergeben sich eine Reihe von Vorteilen, z.B. sind hierdurch keine Inkonsistenzen möglich, die bei "Mutables" möglich sind. Weiterhin ist jedes unveränderbare Objekt auch von Haus aus Thread-safe.
Gibt natürlich auch Nachteile, eben dass du z.B. für jede Änderung ein neues Objekt brauchst...

Du würdest dich bestimmt wundern, wenn du wüsstest wie viele Klassen im JDK unveränderbar sind... Die Klasse String z.B. ist auch ein Immutable

Das heist, dass ich mir entweder so eine dumme Rückgabeklasse machen muss, wenn ich von einer Funktion z.B. ein Objekt und ein bool zurück haben will, oder mir selber ein änderbares Bool bauen muss. Mit Pointer/Referenzen auf Pointer geht ja auch nix.

nep

Hm versteh ich nicht... Wenn du z.B. als Rückgabewert einen Boolean hast, warum willst du da was ändern ? Wenn du nativ einen bool zurückbekommst, kannst du den ja auch nicht ändern (ok in C++ gehts per Referenzen/Pointer). Aber normalerweise macht man sowas auch nicht... Wenn du halt doch z.B. nen bool den du als Rückgabe von einer Funktion bekommst verändern willst, dann musst du tatsächlich den Umweg über eine eigene Hilfsklasse gehen, also z.B. so:

class MyBoolean {
   bool value;
}

Für sowas z.B.

MyObject obj = myFactory.getMyObject(MyBoolean isNew);
if(isNew.value) {
   //Tu dies mit obj
} else {
   //Tu was anderes mit obj
}

nep

Ja da musst du dann eben so ne Hilfsklasse verwenden. Wobei du es aber auch umgekehrt machen könntest, also die Methode einfach den bool returnen lassen und stattdessen MyObject als Objekt übergeben, weil das wird ja eh immer als Referenz übergeben.

So wird das ja vom Prinzip her auch oft bei C++/COM gemacht. Das sieht dann z.B. so aus:
HERSULT myFunc( MyClass** object ) //HRESULT ist im Prinzip auch nur ein long

Das geht ja auch nur, weil es in C Pointer auf Pointer gibt.

Sowas

boolean create(MyObject obj) {
   obj = new MyObject();
}
MyObject obj = null;
boolean isNew = create(obj);
obj.foo(); //NullPointerException;

geht in Java nicht

nep

Oje stimmt ja, wie dumm...
Najo wenn du das dann so machen willst, dann musst du tatsächlich den Umweg über so eine Hilfsklasse gehen

DEvent

Wieso fällt mir einfach kein Fall ein wo sowas überhaupt nötig ist?

Schlimm, ....
Du weisst das Argumenttypen kovariant sind und eine statische Typsicherheit nicht mehr gewährleisten (in C++ mehr als in Java). Was passiert wenn ich deiner Methode eine Reference vom Type MyChildObject übergebe und ich dannach eine Methode wie onlyChildMethod() aufrufe (natürlich nicht in Java). Ich hoffe nichts gutes :-).

grenouille_unreg schrieb:

Schlimm, ....
Du weisst das Argumenttypen kovariant sind und eine statische Typsicherheit nicht mehr gewährleisten (in C++ mehr als in Java). Was passiert wenn ich deiner Methode eine Reference vom Type MyChildObject übergebe und ich dannach eine Methode wie onlyChildMethod() aufrufe (natürlich nicht in Java). Ich hoffe nichts gutes :-).

Hä? Was ist MyChildObject und onlyChildMethod()? Was soll passieren? Die Methode wird ausgeführt.