À la suite de la discussion d'aujourd'hui sur DONC je l'ai déjà lu plusieurs fois la remarque que les structures mutables sont mauvais (comme dans la réponse à cette question).
Quel est le problème réel avec la mutabilité et les structures?
Réponses
Trop de publicités?
Les structures sont des types de valeur ce qui signifie qu'ils sont copiés quand ils sont passés.
Donc, si vous modifiez une copie, vous ne changez que la copie, pas l'original et toutes les autres copies qui pourrait être autour de.
Si votre structure est immuable alors tout automatique des copies du fait d'être passé par valeur sera la même.
Si vous voulez le changer, vous devez consciemment de le faire par la création d'une nouvelle instance de la structure avec les données modifiées. (pas une copie)
Marc Gravell
Points
482669
Par où commencer ;-p
Eric Lippert blog est toujours bon pour un devis:
C'est encore une autre raison pourquoi mutable types de valeur sont le mal. Essayez de toujours faire des types de valeur immuable.
Tout d'abord, vous avez tendance à perdre des changements assez facilement... par exemple, pour obtenir ce à partir d'une liste:
Foo foo = list[0];
foo.Name = "abc";
ce qui fait que le changement? Rien d'utile...
De même avec les propriétés:
myObj.SomeProperty.Size = 22; // the compiler spots this one
vous forçant à faire:
Bar bar = myObj.SomeProperty;
bar.Size = 22;
myObj.SomeProperty = bar;
moins critique, il y a un problème de taille; mutable objets ont tendance à avoir plusieurs propriétés; mais si vous avez une structure avec deux ints, string, DateTime et bool, vous pouvez très rapidement grâce à brûler beaucoup de mémoire. Avec une classe, plusieurs appelants peuvent partager une référence à la même instance (les références sont petites).
Konrad Rudolph
Points
231505
Je ne dirais pas mal , mais la mutabilité est souvent un signe de overeagerness de la part du programmeur pour fournir un maximum de fonctionnalités. En réalité, ce n'est souvent pas nécessaire et qui, à son tour, rend l'interface plus petite, plus facile à utiliser et difficile à utiliser de mal (= plus robuste).
Un exemple de cela est de lire/écrire et écrire/écrire des conflits dans des conditions de course. Ces ne peuvent tout simplement pas se produire dans des structures immuables, car l'écriture n'est pas une opération valide.
Aussi, je demande que la mutabilité est presque jamais nécessaire, le programmeur juste pense qu'il pourrait être dans l'avenir. Par exemple, il n'a tout simplement pas de sens pour modifier une date. Plutôt de créer une nouvelle date basée sur l'ancien. C'est une opération pas cher, de sorte que la performance n'est pas une considération.
JE42
Points
657
Mutable structures ne sont pas mal.
Ils sont absolument nécessaires à une bonne performance des circonstances. Par exemple, lorsque les lignes de cache et ou la collecte des ordures devenir un goulot d'étranglement.
Je ne dirais pas que l'utilisation d'un immuable struct dans ces parfaitement valables cas d'utilisation "mal".
Je peux voir le point C#syntaxe n'aide pas à distinguer l'accès à un membre d'une valeur de type ou d'un type de référence, donc je suis pour préférant immuable des structures, de l'application de l'immutabilité, sur les structures mutables.
Cependant, au lieu de simplement l'étiquetage immuable des structures comme le "mal", je vous conseille d'embrasser la langue et de plaider plus utile et constructif de la règle de pouce.
Par exemple: "les structures sont des types valeur, qui sont copiés par défaut. vous avez besoin d'une référence, si vous ne voulez pas copier"ou "essayer de travailler avec readonly les structures de première".
Morten Christiansen
Points
6467
Types de valeur représente essentiellement immuable concepts. Fx, il ne fait aucun sens d'avoir une valeur mathématique comme un entier, vecteur, etc. et puis être en mesure de le modifier. Ce serait comme redéfinir le sens d'une valeur. Au lieu de changer un type de valeur, il est plus logique d'attribuer une autre valeur unique. Pensez au fait que les types de valeurs sont comparées par la comparaison de toutes les valeurs de ses propriétés. Le point est que si les propriétés sont les mêmes, alors c'est la même représentation universelle de cette valeur.
Comme Konrad mentionne qu'il n'a pas de sens de changer un jour ou l'autre, que la valeur représente que le point unique dans le temps et non pas une instance d'un objet de temps qui a tout de l'état ou du contexte de dépendance.
Espérant que cela fait du sens pour vous. Il est plus sur le concept que vous essayez de capturer avec des types de valeur que les détails pratiques, pour être sûr.
