Scala fournit immuable collections, telles que Set, List, Map. Je comprends que l'immutabilité a des avantages dans les programmes concurrents. Cependant quels sont exactement les avantages de l'immuabilité dans le traitement régulier des données? Et si j'énumère subsets, permutations et combinations par exemple? Est-ce que les collections immutables ont un avantage ici?Quels sont les vrais avantages des collections immuables?
Quels sont exactement les avantages de l'immuabilité dans le traitement régulier des données?
D'une manière générale, les objets immuables sont plus faciles/plus simples à raisonner.
C'est le cas. Puisque vous enumerez sur une collection, vous voudrez probablement être certain que les éléments ne sont pas ajoutés ou supprimés par inadvertance pendant que vous enumerez.
L'immutabilité est un paradigme de la programmation fonctionnelle. Rendre les collections immuables permet de les considérer comme des types de données primitifs (ie modifier une collection ou tout autre objet en créant un objet différent tout comme ajouter 2 à 3 ne modifie pas 3, mais crée 5)
C'est un commentaire très intéressant - il semble que cela vous donne une sémantique "transactionnelle" sur vos données, c'est à dire si vous faites pour ((k, v) <- myMap) {quelque chose (k, v)} 'et quelqu'un fait 'myMap + = k2 -> v2' à l'intérieur de' something', vous itérez encore sur un instantané de ce que 'myMap' avait quand vous avez démarré la boucle. Droite? Je n'ai jamais pensé à ça. –
Si vos données ne changent pas après la création, utilisez des structures de données immuables. Le type que vous choisissez identifiera l'intention d'utilisation. Quelque chose de plus spécifique nécessiterait des connaissances sur votre espace de problème particulier.
Vous pouvez vraiment être à la recherche d'un sous-ensemble, d'une permutation ou d'un générateur de combinaison, puis la discussion sur les structures de données est sans objet.
En outre, vous avez mentionné que vous comprenez les avantages simultanés. Vraisemblablement, vous lancez un algorithme sur les permutations et les sous-ensembles, et il y a de fortes chances que cet algorithme puisse être parallélisé dans une certaine mesure. Si tel est le cas, l'utilisation de structures immuables à l'avance garantit que votre implémentation initiale de l'algorithme X sera facilement transformée en algorithme X concurrent.
Pour développer la réponse de Matt: D'après mon expérience personnelle, je peux dire que les implémentations d'algorithmes basés sur les arbres de recherche (ex: largeur en premier, profondeur en premier, backtracking) en utilisant des collections mutables finissent régulièrement comme un tas de merde: soit vous oubliez de copier une collection avant un appel récursif, soit vous ne retirez pas les modifications correctement si vous récupérez la collection. Dans cette zone, les collections immuables sont clairement supérieures. J'ai fini par écrire ma propre liste immuable en Java alors que je ne pouvais pas avoir de problème avec les collections de Java. Et voilà, la première implémentation "immuable" a fonctionné immédiatement.
J'espère que vous n'avez pas écrit cette implémentation de liste immuable à tout moment depuis peu, puisque nous avons eu ['Collections # unmodifiableList()' (Java SE)] (http://download.oracle.com/javase/7/docs /api/java/util/Collections.html#unmodifiableList%28java.util.List%29) et ['ImmutableList' (Google Guava)] (http://docs.guava-libraries.googlecode.com/git-history/ v9.0/javadoc/com/google/common/collect/ImmutableList.html) pendant un moment. –
'nonmodifiableList' n'est pas utile du tout, par ex. vous ne pouvez pas obtenir une liste avec un élément supplémentaire de retour ou plus. La goyave est cool, mais parfois exagérée. La meilleure implémentation de liste immuable que je connaisse vient de http://functionaljava.org – Landei
J'ai quelques avantages à ajouter à la liste:
collections Immuable ne peuvent pas être invalidés de sous vous
C'est, il est tout à fait bien d'avoir des membres immuables de val publique de une classe Scala. Ils sont en lecture seule par définition. Comparez avec Java où non seulement vous devez vous souvenir de rendre le membre privé mais également écrire une méthode get qui renvoie une copie de l'objet afin que l'original ne soit pas modifié par le code appelant.
Les structures de données immuables sont persistantes.Cela signifie que la collection immuable obtenue en appelant filter sur votre TreeSet partage en fait certains de ses nœuds avec l'original. Cela se traduit par des économies de temps et d'espace et compense certaines des pénalités encourues en utilisant l'immuabilité.
certains des avantages immutabilité:
1 - plus petite marge d'erreur (vous savez toujours ce qui est dans vos collections et variables en lecture seule). 2 - vous pouvez écrire des programmes concurrents sans vous soucier de l'interaction des threads les uns avec les autres lors de la modification des variables et des collections.
Moins d'état = moins d'analyse. –
Ce qui permet aux outils (c'est-à-dire aux compilateurs) de faire plus d'optimisations – michid
Je suis d'accord, et cela signifie que l'utilisation d'objets immuables produit du code qui est plus souvent correct la première fois. Avec le typage statique, le code Scala nécessite un débogage remarquablement faible. –