Von Java zu Kotlin

Kapitel 5. Von Bohnen zu Werten

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Viele Java-Projekte haben sich für veränderbare JavaBeans oder POJOs (plain old Java object) entschieden, um Daten zu repräsentieren. Die Veränderbarkeit bringt jedoch Komplikationen mit sich. Warum sind unveränderliche Werte die bessere Wahl und wie können wir die Kosten der Veränderbarkeit in einer Codebasis reduzieren?

Bohnen

Wie in "Bean Style" erläutert hat , wurden JavaBeans eingeführt, um die Entwicklung von Drag-and-Drop-GUI-Buildern im Stil von Visual Basic zu ermöglichen. Ein Entwickler konnte eine Schaltfläche auf einem Formular ablegen, ihren Titel und ihr Symbol ändern und dann einen On-Click-Handler verdrahten. Hinter den Kulissen schrieb der GUI-Builder Code, um ein Schaltflächenobjekt zu instanziieren und dann Setter für die Eigenschaften aufzurufen, die der Entwickler geändert hatte.

Um eine JavaBean zu definieren, braucht eine Klasse einen Standardkonstruktor (ohne Argumente), Getter für ihre Eigenschaften und Setter für ihre veränderbaren Eigenschaften. (Die Anforderung Serializable lassen wir mal außen vor, denn selbst Sun hat das nie wirklich ernst genommen.) Das ist sinnvoll für Objekte, die viele Eigenschaften haben. GUI-Komponenten haben typischerweise Vorder- und Hintergrundfarben, Schriftart, Beschriftung, Rahmen, Größe, Ausrichtungen, Abstände usw. Meistens sind die Standardwerte für ...