2010-07-29 18 views
24

Duplicar posibles:
What are the benefits to marking a field as readonly in C#?¿Por qué usar sólo lectura en C#

siempre he utilizado la palabra clave de sólo lectura en C# en situaciones donde sé que lo único que necesita para establecer la referencia de un objeto una vez (por ejemplo, una conexión de servicio WCF en una página ASP.NET). Aparte de simplemente asegurar que los objetos no se pueden configurar más de una vez, ¿cuáles son las ventajas de usar solo de forma legible sobre una referencia estándar como la estática privada o privada? Parece vago ¿Hay implicaciones de rendimiento?

Respuesta

26

Dejando a un lado las diferencias de rendimiento, yo diría que la gran ventaja es que proporciona información útil sobre qué es la variable y para qué se utiliza (edite: esto tiene incluso más valor cuando otra persona se hace cargo del mantenimiento de su código ...)

Además, como usted dijo, evita que alguien sobrescriba lo que usted quiso decir que era un valor constante. Creo que solo es una justificación suficiente para su uso ...

28

readonly existe únicamente para evitar que cualquiera, ya sea accidental o intencionalmente, cambie el valor de una variable una vez establecida. Se aplica en tiempo de ejecución.

const es similar, pero se aplica en tiempo de compilación. Por lo tanto, el valor debe establecerse en el momento en que se crea la variable.

Cualquiera de estos se puede combinar con otros modificadores, como public, private o static.

+0

que he leído varias descripciones de 'readonly' y los tuyos parecen diferir. ¿Estás seguro de que es correcto? Soy un chico de Java, pero por lo que he leído, 'readonly' solo evita reasignar la referencia fuera de constructor o declaración. Lo que estás escribiendo se parece mucho al 'final' de Java. – Vlasec

8

Un campo readonly solo se puede establecer al inicializar el campo o en un constructor. Esto proporciona un beneficio considerable para el mantenimiento continuo porque puede estar seguro de que se estableció cuando el objeto se creó y no se cambió a un objeto diferente desde entonces. No hay beneficio de rendimiento.

En general, no debe marcar un campo de tipo mutable como de solo lectura porque el objeto mismo se puede modificar posteriormente. FxCop define una regla de advertencia para esto - http://msdn.microsoft.com/en-us/library/ms182302(v=vs.120).aspx

+4

El objeto PUEDE ser modificado si es un tipo de referencia mutable. Los artículos se pueden agregar a una lista declarada de solo lectura. –

+2

No debe declarar tipos de referencia de solo lectura por ese motivo: http://msdn.microsoft.com/en-us/library/ms182302%28VS.80%29.aspx. Pero es un buen punto para que aparezca. –

+4

@DavidNeale: Saber que un campo de tipo referencia siempre apuntará al mismo objeto suele ser información muy útil, incluso si varias propiedades del objeto pueden cambiar.Entre otras cosas, en cualquier nivel dado de abstracción, es mucho más fácil mantener la seguridad de la hebra cuando solo hay un nivel de mutabilidad que cuando hay dos o más (esa es una razón importante 'List ' no es seguro para subprocesos , incluso para escenarios de solo agregación donde 'T' es un tipo de referencia) - contiene una referencia mutable a una matriz mutable. – supercat

2

La claridad de la finalidad y el uso parece ser la mejor razón para usar readonly. Aunque podría argumentar que puede dejar de escribir simplemente porque aún no está asegurado y no es necesario.

2

Sólo recuerde que mientras que el árbitro no puede ser cambiado para sólo lectura, si el objeto es mutable del estado del objeto todavía puede ser cambiado (es decir, los puntos añadidos a una lista)