J'ai lu Question et quelques autres réponses et pendant que je reçois la différence entre modifier la référence et changer l'état de l'instance actuelle, je ne suis pas certain que cela signifie que je ne devrais pas la marquer en lecture seule. Est-ce parce que le marquage de quelque chose en tant que réadien dit au compilateur quelque chose de spécial à propos de l'instance et il est donc capable de le traiter comme un fil sûr quand il pourrait ne pas être?
On peut supposer que il y a des situations où je ne veux pas l'instance pour pouvoir être changé, mais ne me dérange pas si l'état de l'instance est modifié (singleton peut-être. / Me prépare pour les flammes) Quelles sont les conséquences pour Marquage de l'instance Readonly si je le veux?
4 Réponses :
Je pense que le point est que cela pourrait être trompeur - un lecteur imprudent pourrait supposer que une variable réadonnée était effectivement une constante, ce qui ne serait pas.
Je traiterais cela comme une suggestion plus qu'une règle - il y a certainement des cas où cela pourrait être raisonnable, mais devrait être utilisé avec soin. (En particulier, je serais nerveux si l'état mutable était exposé au monde extérieur.)
Il n'y a pas de conséquences (runtime / environnement). Le compilateur ne fabulera pas, votre runtime n'explosera pas, et tout ira généralement bien.
Ce n'est que FXCop (un outil d'analyse statique que certaines personnes utilisent) qui a un avertissement à ce sujet. Les raisons de l'avertissement sont expliquées dans le thread que vous avez liées (sémantiquement, il peut ne pas être clair que l'objet n'est pas réellement "readonly", seulement que la variable ne peut pas être "réaffectée").
Personnellement, je ne suis pas d'accord avec la règle, alors je voudrais juste le désactiver (si vous exécutez FXCop et cela vous concerne).
Merci, c'est ce que je voulais savoir que je voulais juste être sûr que le temps d'exécution ne ferait aucune hypothèse sur ce membre en fonction du fait qu'il était marqué comme réadonn
Lecture de l'article relié par Eric, je ne pense pas que je devrais ignorer cette règle. La déclaration réadonnée peut mettre en œuvre un comportement assez différent de ce que vous attendez.
@Rafa: Si un champ identifiant un objet de classe mutable est marqué loadonly , une copie de la référence fournira une vue en direct de l'état encapsulé par le champ. Si le champ n'est pas marqué loadonly , une copie de la référence peut devenir détachée de l'état encapsulé par le champ. Que certaines personnes ne savent pas ce que loadonly signifie lorsqu'il est appliqué à une référence à un objet mutable ne signifie pas que son sens réel n'est pas utile.
Un point associé intéressant: mutable lisonly les structures sont une mauvaise idée en raison de situations telles que celle-ci:
http://ericlippert.com/2008/05/14/mutant -Readonly-structs /
La plupart des personnes à qui j'ai montré que ce code est incapable de prédire correctement sa production.
Les structures réadonnées mutables ont le problème que les gens pensent qu'ils les mutaient, mais ils montent vraiment une copie.
Types de RefAnly mutables ont le problème opposé. Les gens pensent qu'ils sont profondément immuables, mais ils ne sont que peu totalement immuables.
Ces deux déclarations de type sont valides et utiles, bien qu'ils veulent dire des choses différentes:
Si vous voulez vraiment une référence constante à un objet mutable il semble inacceptable d'être obligé de se contenter d'une référence mutable pour une raison quelconque, encore moins mauvaise. Dans la programmation multi-thread la référence constante pourrait vous éviter d'avoir à synchroniser sur l'objet de posséder (il vous reste à synchroniser sur l'objet mutable par la référence, mais c'est un verrou plus fin). P>
lecteurs imprudents sont probablement écrivains imprudents aussi - ne peut pas faire grand-chose à leur sujet court: p>
Object const* const constantPointerToConstantObject = ...;