Beschreiben Sie den Mechanismus der Sammlungen in Kotlin: Unterschiede zwischen List, MutableList, Set, MutableSet, Map, MutableMap. Welche Fallstricke können bei ihrer Verwendung auftreten? Geben Sie Codebeispiele.

Antwort.

Kotlin bietet zwei Arten von Sammlungen: immutable (unveränderlich) und mutable (veränderlich).

• List — unveränderliche Liste. Elemente können nicht hinzugefügt/entfernt werden.
• MutableList — veränderliche Liste: Elemente können hinzugefügt und entfernt werden.
• Set — unveränderliche Menge (eindeutige Elemente).
• MutableSet — veränderliche Menge.
• Map — assoziatives Array (Schlüssel-Wert), unveränderlich.
• MutableMap — veränderliches assoziatives Array.

Codebeispiel:

val fruits: List<String> = listOf("Apfel", "Banane", "Kirsche")
val mutableFruits: MutableList<String> = mutableListOf("Apfel", "Banane")
mutableFruits.add("Kirsche")

val fruitSet: Set<String> = setOf("Apfel", "Banane") // Eindeutigkeit der Elemente
val mutableFruitSet: MutableSet<String> = mutableSetOf("Apfel", "Banane")
mutableFruitSet.add("Kirsche")

val scores: Map<String, Int> = mapOf("Tom" to 80, "Jane" to 90)
val mutableScores: MutableMap<String, Int> = mutableMapOf("Tom" to 80)
mutableScores["Jane"] = 90

Feinheiten:

• Sammlungen sind standardmäßig unveränderlich.
• Viele Funktionen, die Listen aus der Standardbibliothek zurückgeben, geben List (nicht MutableList) zurück.
• Bei der Arbeit mit Sammlungen ist es wichtig, die nicht für Änderungen gedachten nicht zu verändern.

Fangfrage.

Wenn Sie eine Funktion haben, die List<T> als Parameter akzeptiert, können Sie diese Liste innerhalb der Funktion auf irgendeine Weise ändern?

Antwort: Nein, wenn der Parameter vom Typ List<T> ist, können innerhalb der Funktion keine Elemente hinzugefügt oder entfernt werden. Aber wenn tatsächlich eine MutableList<T> übergeben wurde, kann sie in diesen Typ umgewandelt werden (was ein Risiko mit sich bringt):

fun modifyList(list: List<String>) {
    if (list is MutableList) {
        list.add("Ein weiteres") // Funktioniert, wenn die ursprüngliche Sammlung veränderlich ist
    }
}

Das sollte nicht gemacht werden, da es den Vertrag verletzt (List soll unveränderlich sein!).

Beispiele für echte Fehler aufgrund mangelnden Wissens über die Feinheiten dieses Themas.

---

Geschichte

In einem großen Projekt wurde eine Funktion verwendet, die List<Customer> akzeptierte, und sie versuchten, innerhalb der Funktion ein neues Element hinzuzufügen. Der Kompilierungsfehler (add/clear/remove sind nicht für List definiert) wurde erst bei der Überprüfung entdeckt, da eine veränderliche Liste für die Datenumwandlung erforderlich war.

---

Geschichte

Die Sammlung wurde als MutableList deklariert, aber ohne Synchronisation in mehreren Threads übergeben. Dies führte zu konkurrierenden Änderungen, die zu "ConcurrentModificationException" und einer Beschädigung des Listenstatus führten. Der Fehler wurde lange gesucht, da die Thread-Sicherheit nicht berücksichtigt wurde.

---

Geschichte

In einem der Dienste zur Verarbeitung von Abfrageergebnissen aus der Datenbank wurde mutableListOf verwendet, und dann wurde der Verweis nach außen übergeben. Ein externer Code löschte versehentlich die Liste. Infolgedessen kamen leere Daten beim Benutzer an, da die Verweise nicht kopiert wurden und mutable Sammlungen außerhalb der Geschäftsschicht modifiziert wurden.