val-mutable versus var-immutable dans Scala

Existe-t-il des directives dans Scala sur le moment d'utiliser val avec une collection mutable par rapport à l'utilisation de var avec une collection immuable? Ou devriez-vous vraiment viser le val avec une collection immuable?

Le fait qu'il existe les deux types de collections me donne beaucoup de choix, et souvent je ne sais pas comment faire ce choix.

Question assez courante, celle-ci. Le plus difficile est de trouver les doublons.

Vous devez viser la transparence référentielle . Cela signifie que si j'ai une expression «e», je pourrais créer un val x = eet le remplacer epar x. C'est la propriété qui rompt la mutabilité. Chaque fois que vous avez besoin de prendre une décision de conception, maximisez la transparence référentielle.

En pratique, une méthode locale varest la plus sûre varqui existe, car elle n'échappe pas à la méthode. Si la méthode est courte, c'est encore mieux. Si ce n'est pas le cas, essayez de le réduire en extrayant d'autres méthodes.

D'un autre côté, une collection mutable a le potentiel de s'échapper, même si ce n'est pas le cas. Lors du changement de code, vous pouvez alors vouloir le passer à d'autres méthodes ou le renvoyer. C'est le genre de chose qui brise la transparence référentielle.

Sur un objet (un champ), à peu près la même chose se produit, mais avec des conséquences plus désastreuses. Dans tous les cas, l'objet aura un état et, par conséquent, rompra la transparence référentielle. Mais avoir une collection mutable signifie que même l'objet lui-même peut perdre le contrôle de qui le change.

Si vous travaillez avec des collections immuables et que vous avez besoin de les «modifier», par exemple, y ajouter des éléments dans une boucle, vous devez utiliser vars car vous devez stocker la collection résultante quelque part. Si vous ne lisez qu'à partir de collections immuables, utilisez vals.

En général, assurez-vous de ne pas confondre références et objets. vals sont des références immuables (pointeurs constants en C). Autrement dit, lorsque vous utilisez val x = new MutableFoo(), vous pourrez changer l'objet vers lequel xpointe, mais vous ne pourrez pas changer vers quel objet x pointe. Le contraire est vrai si vous utilisez var x = new ImmutableFoo(). Reprenant mon premier conseil: si vous n'avez pas besoin de changer vers quel objet une référence pointe, utilisez vals.

La meilleure façon de répondre est de donner un exemple. Supposons que nous ayons un processus qui collecte simplement des nombres pour une raison quelconque. Nous souhaitons enregistrer ces numéros et enverrons la collection à un autre processus pour ce faire.

Bien sûr, nous continuons à collecter des numéros après avoir envoyé la collection à l'enregistreur. Et disons qu'il y a une surcharge dans le processus de journalisation qui retarde la journalisation réelle. J'espère que vous pouvez voir où cela va.

Si nous stockons cette collection dans un mutable val, (mutable car nous y ajoutons continuellement), cela signifie que le processus effectuant la journalisation examinera le même objet qui est toujours mis à jour par notre processus de collecte. Cette collection peut être mise à jour à tout moment, et donc quand il est temps de se connecter, il se peut que nous n'enregistrions pas réellement la collection que nous avons envoyée.

Si nous utilisons un immuable var, nous envoyons une structure de données immuable à l'enregistreur. Lorsque nous ajouterons plus de numéros à notre collection, nous remplacerons notre varpar une nouvelle structure de données immuable . Cela ne signifie pas que la collecte envoyée à l'enregistreur est remplacée! Il fait toujours référence à la collection qui lui a été envoyée. Notre enregistreur enregistrera donc bien la collection qu'il a reçue.

Je pense que les exemples de cet article de blog éclaireront davantage, car la question de savoir quel combo utiliser devient encore plus importante dans les scénarios de concurrence: importance de l'immuabilité pour la concurrence . Et pendant que nous y sommes, notez l'utilisation préférée de synchronized vs @volatile vs quelque chose comme AtomicReference: trois outils

var immutable contre. val mutable

En plus de nombreuses excellentes réponses à cette question. Voici un exemple simple, qui illustre les dangers potentiels de val mutable:

Les objets mutables peuvent être modifiés à l'intérieur de méthodes, qui les prennent comme paramètres, tandis que la réaffectation n'est pas autorisée.

import scala.collection.mutable.ArrayBuffer

object MyObject {
    def main(args: Array[String]) {

        val a = ArrayBuffer(1,2,3,4)
        silly(a)
        println(a) // a has been modified here
    }

    def silly(a: ArrayBuffer[Int]): Unit = {
        a += 10
        println(s"length: ${a.length}")
    }
}

Résultat:

length: 5
ArrayBuffer(1, 2, 3, 4, 10)

Une telle chose ne peut pas se produire avec var immutable, car la réaffectation n'est pas autorisée:

object MyObject {
    def main(args: Array[String]) {
        var v = Vector(1,2,3,4)
        silly(v)
        println(v)
    }

    def silly(v: Vector[Int]): Unit = {
        v = v :+ 10 // This line is not valid
        println(s"length of v: ${v.length}")
    }
}

Résulte en:

error: reassignment to val

Étant donné que les paramètres de fonction sont traités, valcette réaffectation n'est pas autorisée.