Von Java zu Kotlin

Kapitel 15. Gekapselte Sammlungen zu Typaliasen

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

In Java kapseln wir Sammlungen von Objekten in Klassen, um die Mutation und das Hinzufügen von Operationen zu kontrollieren. In Kotlin ist die Kontrolle der Mutation weniger wichtig, und wir können Erweiterungsfunktionen verwenden, um Operationen hinzuzufügen. Wie würden unsere Entwürfe ohne die Kapselung besser sein und wie kommen wir dahin?

In Kapitel 6 haben wir uns die Unterschiede zwischen Java und Kotlin angesehen, wenn es um Sammlungen geht. Javas Sammlungsschnittstellen sind entsprechend ihrer objektorientierten Wurzeln grundsätzlich veränderbar, während Kotlin Sammlungen als Werttypen behandelt. Wie wir gesehen haben, können wir in alle möglichen Schwierigkeiten geraten, wenn wir gemeinsame Sammlungen verändern. Wir könnten diese Probleme vermeiden, indem wir gemeinsame Sammlungen nicht verändern ("Don't Mutate Shared Collections"), aber in Java ist das schwer zu bewerkstelligen, wenn die Methoden add und set nur eine Autovervollständigung entfernt sind. Anstelle von Konventionen und Disziplin entscheidet sich der meiste Java-Code vernünftigerweise für den sichereren Ansatz, rohe Sammlungen einfach nicht zu teilen. Stattdessen werden Sammlungen in einem anderen Objekt versteckt.

Hier ist zum Beispiel eine Route in Travelator:

public class Route {
    private final List<Journey> journeys;