Descrivi il meccanismo di funzionamento delle collezioni in Kotlin: differenze tra List, MutableList, Set, MutableSet, Map, MutableMap. Quali insidie possono sorgere durante il loro utilizzo? Fornisci esempi di codice.

Risposta.

Kotlin offre due tipi di collezioni: immutable (immutabili) e mutable (mutabili).

• List — lista immutabile. Non è possibile aggiungere o rimuovere elementi.
• MutableList — lista mutabile: è possibile aggiungere e rimuovere elementi.
• Set — insieme immutabile (elementi unici).
• MutableSet — insieme mutabile.
• Map — array associativo (chiave-valore), immutabile.
• MutableMap — array associativo mutabile.

Esempio di codice:

val fruits: List<String> = listOf("Apple", "Banana", "Cherry")
val mutableFruits: MutableList<String> = mutableListOf("Apple", "Banana")
mutableFruits.add("Cherry")

val fruitSet: Set<String> = setOf("Apple", "Banana") // Unicità degli elementi
val mutableFruitSet: MutableSet<String> = mutableSetOf("Apple", "Banana")
mutableFruitSet.add("Cherry")

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

Sfumature:

• Le collezioni per impostazione predefinita sono immutabili.
• Molte funzioni che restituiscono elenchi dalla libreria standard restituiscono List (e non MutableList).
• È importante non modificare le collezioni che non sono state progettate per essere modificate.

Domanda trabocchetto.

Se hai una funzione che accetta List<T> come parametro, puoi in qualche modo modificare questo elenco all'interno della funzione?

Risposta: No, se il parametro è di tipo List<T>, non è possibile aggiungere/rimuovere elementi all'interno della funzione. Ma se viene effettivamente passato un MutableList<T>, è possibile convertirlo a questo tipo (cosa che introduce rischi):

fun modifyList(list: List<String>) {
    if (list is MutableList) {
        list.add("Another") // Funziona se la collezione originale è mutabile
    }
}

Non è consigliabile fare così, poiché viola il contratto (List deve essere immutabile!).

Esempi di errori reali dovuti alla mancata conoscenza delle sfumature del tema.

---

Storia

In un grande progetto è stata utilizzata una funzione che accetta List<Customer>, e si è cercato di aggiungere un nuovo elemento all'interno della funzione. L'errore di compilazione (add/clear/remove non definiti per List) è stato scoperto solo durante la revisione, poiché era richiesto un elenco mutabile per la trasformazione dei dati.

---

Storia

La collezione era dichiarata come MutableList, ma veniva passata a più thread senza sincronizzazione. Di conseguenza, si sono verificati cambiamenti concorrenti che hanno portato a "ConcurrentModificationException" e corruzione dello stato dell'elenco. L'errore è stato cercato a lungo, poiché non è stata presa in considerazione la sicurezza dei thread.

---

Storia

In uno dei servizi per lavorare con i risultati delle query del DB veniva utilizzato mutableListOf, poi si restituiva il riferimento all'esterno. Il codice esterno per errore cancellava l'elenco. Di conseguenza, all'utente arrivavano dati vuoti, poiché i riferimenti non venivano clonati e le collezioni mutabili venivano modificate al di fuori dello strato di logica aziendale.