Best Practice Java und unmodifiable

[thecain]

Ich wollte mal nachfragen wie ihr es mit Java und umodifiable handhabt.

Prä-Java 9 war das noch keine so grosse Diskussion. In den letzten Jahren ist jedoch das Konzept unmodifiable immer mehr aufgekommen, auch durch Sprachen wie Javascript und den vermehrten funktionalen Aspekten von Java.

Als Beispiel:
List.of(...) erzeugt ja z.B. auch eine Unmodifiable List (was man aufgrund der Rückwärtskompatibiltät der Klasse leider nicht ansieht, aber das ist ein anderes Thema)

Wie handhabt ihr es so? Macht ihr eure Klassen unmodifiable? Wie handhabt ihr dann z.B. ein "add" zu einer List.

Ich finde z.B.

var new= new MyObject(old.x,
old.y,
Stream.concat(Stream.of(newValue), old.list.stream()).collect(Collectors.toList());

sehr umständlich.

Hab ich hier irgend ein Pattern verpasst, ist Java in einer komischen Zwischenphase oder bin ich mit Unmodifiable komplett auf dem Holzweg?

 

[LimDul]

Wenn du in eine unmodifiable Klasse was hinzufügen willst ist entweder

* Dein Ansatz falsch
* Die Verwendung der Klasse falsch
* Die unmodifiable Klasse ist eine falsche Modellierung
(Ausnahmen gibt es)

Bei den Listen ist, wenn dann so, dass man eine neue liste macht, da mit addAll alles aus der unmodifiable List ergänzt und dann das ergänzt was fehlt. Allerdings wie gesagt, kann das schnell ein Code Smell sein.

Entweder hätte man es auch ohne unmodifiable Listen gemacht (weil man eh aus mehreren Listen eine machen muss/will) - oder es ist fachlich fragwürdig diese Liste zu erweitern.

 

[thecain]

Ich stimme dir zu, aber das ist nicht worauf ich hinaus will.

Ich meine wirklich komplett immutable (jetzt fällt mir endlich das Wort wieder ein. Unmodifiable ist sonst ja nicht so gebräuchlich, ausser bei Java Lists.)

Jede Änderung an einem Objekt erzeugt ein neues Objekt. Das vermeidet in der viele Probleme und ist sehr performant, weil nie ein DeepEquals gemacht werden muss, sondern immer Referenzen verglichen werden können. So die Theorie. In JavaScript ist das z.B sehr gut umsetzbar mit dem Spread Operator...

 

[mrBrown]

Meine ganz generelle Sicht dazu, nicht nur zu Listen:

Grundsätzlich würd ich da trennen zwischen Value-Typen, Entitäten und "sonstigen" Java-Klassen.

Erstere sind (bei mir) immer gänzlich unveränderlich in dem Sinne, dass direkte Felder und alle Collections darin nicht veränderlich sind. Wenn man dort Änderungen braucht, muss man immer ein neues Objekt erstellen – entweder direkt über Konstruktor/Factory-Methode, oder über "with"-Methoden. Dort würde man die unveränderlichen Kopie Listen direkt im Konstruktor erzeugen.
Dort wäre auch die einzige Notwendigkeit, eine unveränderlichen verändern zu müssen, der übliche Weg wäre dabei, eine "normale" Collection draus mach, diese verändern, und dann daraus wieder eine unveränderlich Liste erzeugen (letzteres passiert aber meist eher implizit)

Entitäten können im Gegensatz dazu dann verändert werden – im Idealfall aber immer nur über explizite Methode, also "setter" (fachliche Methode zum verändern) für normale Felder und für Collections explizite Methode um diese zu verändern, innerhalb der Klasse ist die Collection also veränderbar. Über den "getter" bekommt man aber nie die veränderliche Liste, sondern dort wird immer eine unveränderlichen Kopie erzeugt. Notwendigkeit, diese Liste zu verändern, sollte es aber meist auch nicht geben, da es eben "am Rest vorbei gehen" würde, und

"normale" Klassen wären dann sowas wie zB DTOs, die können und dürfen verändert werden, da gibts keine unveränderlichen Listen oder sonstiges, sondern eher Getter/Setter für alles.

Das vermeidet in der viele Probleme und ist sehr performant, weil nie ein DeepEquals gemacht werden muss, sondern immer Referenzen verglichen werden können.

Wobei das Pattern nur in bestimmten Fällen möglich ist, zB State-Management wie man es aus Redux oder React kennt, weil dort ein "fälschlicherweise als ungleich erkannt" keine wirklichen Auswirkungen hat.

 

[DrPils]

Value-Typen

sorry aber was ist denn unter Value-Typen zu verstehen

 

[kneitzel]

Das vermeidet in der viele Probleme und ist sehr performant, weil nie ein DeepEquals gemacht werden muss, sondern immer Referenzen verglichen werden können.

Das hat @mrBrown zwar schon gesagt, aber ich wollte dazu noch einmal klarere Worte finden: Diese Aussage so ist falsch!

Man muss sich nur String als Beispiel ansehen:
String ist immutable - aber Strings werden nicht per Referenz verglichen.

Und das ist das "normale" - es gibt Lösungen, die den Vergleich per Referenz ermöglichen - aber das sind dann spezielle Lösungen. String kann man hier ebenfalls etwas als Beispiel nehmen - denn durch intern() bekommt man Strings, die direkt vergleichbar sind.

sorry aber was ist denn unter Value-Typen zu verstehen

Value Types meint Primitive types aus der JLS 4.2: also int, bool, double, ....
In dem Zusammenhang von @mrBrown natürlich klassen, die dann einen Wert darstellen. Ein Beispiel könnte z.B. eine Klasse Bruch sein. Die stellt einen Wert da, mit dem man rechnen kann ...
Im Gegensatz dazu dann Entities, die sozusagen eine Art Datensatz sind. Beispiel wäre z.B. eine Klasse Person, die hat einen Namen, mehrere Adressen, ...

 

[httpdigest]

Value Types sind Typen, deren Instanzen eindeutig über den Wert ihrer Elemente vergleichbar bzw. identifiziert sind und nicht über die Objekt-Referenz/Objektidentität (im Sinne von Javas '==').
Das trifft zum einen für die primitiven Typen zu, aber ist auch sehr erstrebenswert für komplexe/zusammengesetzte Typen, wenn die Gleichheit solcher Typen sich nur aus den Wertekonstellationen ergibt.

Value Types meint Primitive types aus der JLS 4.2: also int, bool, double, ....

Naja, hier geht es insbesondere eben nicht nur um die primitiven Typen, sondern auch um komplexe Typen, die als Values zu behandeln sind. Hierzu bietet JDK Valhalla mit Value Types auch eine bessere Unterstützung als z.B. nur @Value per Lombok etc.

 

[kneitzel]

Naja, hier geht es insbesondere eben nicht nur um die primitiven Typen, sondern auch um komplexe Typen, die als Values zu behandeln sind. Hierzu bietet JDK Valhalla mit Value Types auch eine bessere Unterstützung als z.B. nur @Value per Lombok etc.

Ja, der Zusammenhang im Post von mrBrown war wichtig. Das war mir dann auch noch aufgefallen und hatte dann meinen Beitrag noch einmal editiert. Values sind dann Dinge, die für sich als Wert stehen.

 

[thecain]

Stimmt natürlich.. Ich war da zu fest auf das Change-Detection Konzept von gewissen Frameworks eingeschossen.

Die Frage kam von mir dadurch auf, dass ich in letzter Zeit vermehrt auch mit Javascript unterwegs war und das Konzept eigentlich sehr zu schätzen gelernt habe. Nun habe ich bei einem privaten Projekt versucht auch mit Java mehr in diese Richtung zu gehen, habe aber feststellen müssen, dass es sehr umständlich ist.

Eure Beiträge bekräftigen mich jetzt aber auch in meinem Schluss, dass Java dafür 1. nicht die geeignetste Sprache ist und 2. nicht jedes Konzept überall funktioniert. So ähnlich wie @mrBrown habe ich es vorher gehalten und werde das entsprechend auch beibehalten.

Danke für eure Beiträge

 

[LimDul]

Aus Neugierde, was kann Javascript da, was Java nicht kann? (Ohne Bewertung, ich bin da bei dir, dass nicht jedes Konzept für jede Sprache/jeden Anlass passend ist)

 

[thecain]

z.B. in Angular wird sehr viel Reaktiv programmiert. Eine UI-Komponente hat einen Input und refresht sich nur "OnPush".
Das heisst wenn entweder:
- Ein Event tritt auf
- Change Detection wird Manuell auslöst
- Das Objekt ändert sich

Die ChangeDetection löst aber nur aus, wenn sich die Referenz des Objekts ändert.

Dies funktioniert in Javascript wie folgt und das gibt dann auch komplett neue Objekte mit neuen Referenzen:

Für Arrays const newArray = [...oldArray, newElement]
oder für objekte const newObject = {...oldObject, newAttribute}

Das ist natürlich sehr praktisch zu schreiben.