Al escribir una clase en C#, ¿es una buena idea marcar todas las variables de miembros privados como de solo lectura si solo están asignadas en el constructor y no están sujetas a cambios en otras partes de su ¿clase? ¿O es esto exagerado?Clase C# y miembros de solo lectura
Sí, personalmente creo que es una buena idea. Intento mantener los tipos inmutables siempre que sea posible, y declarar una variable readonly es una buena start a eso. No es el todo y el final, por supuesto, si esa variable es algo mutable (por ejemplo, StringBuilder o una matriz), entonces realmente no está ayudando mucho. Aun así, haré que la variable sea de solo lectura para que sea obvio que no quiero cambiar el valor de la variable en sí, y para evitar hacerlo accidentalmente en otra parte de la misma clase, posiblemente meses o años después.
eres un gurú en Java y C#. Este es esencialmente el equivalente de C# de esta pregunta de Java. http://stackoverflow.com/questions/137868/using-final-modifier-whenever-applicable-in-java Me pregunto por qué la discusión aquí parece mucho más tersa que la de Java. – RAY
@RAY: No, tenga en cuenta que 'final' en Java se aplica a más que solo variables; es una combinación de' readonly' y 'sealed' en C# ... y si comienza preguntándole a las personas si las clases deben sellarse o no no, verás un debate más acalorado ... –
Es cierto. Sin embargo, la pregunta específicamente relacionada con las preguntas sobre variables locales y de clase (argumentos y campos) ... – RAY
Sí, eso es lo que readonly específicamente indica. Si ya sabe (o puede asumir al menos) que no va a asignarlo a ningún otro lugar, marcarlo readonly es una buena idea. Después de todo, es más fácil eliminar readonly que agregarlo más tarde.
Sí, no se encontrará con problemas con la modificación posterior de sus valores por algún código escrito por otro desarrollador que no sabía que deberían ser de solo lectura.
Vaya buena pregunta y una que simplemente va a ser respondida con opiniones. Mi opinión es que siempre solo creo propiedades para la variable. Un ejemplo es el siguiente.
private int _myInt;
private int myInt {get{return _myInt;}}
Aún permite que la variable se mute dentro de la clase; no indica la intención del desarrollador * no * mutarla dentro de otra clase. método. –
Si solo voy a inicializar una variable una vez y nunca escribir en ella, lo haría const.
No se puede hacer const si el valor no será una constante en tiempo de compilación, o si se trata de un campo de instancia. –
Correcto, considero que const es más eficiente porque * is * compile-time.Si el miembro no puede ser const, entonces se necesitará otra ruta como readonly. De lo contrario, lo haría const. –
Incluso si es del tipo correcto, aún así podría ser una mala idea hacerlo const. Por ejemplo, supongamos que tiene un campo int "VersionNumber". No * hagas eso const, hazlo de solo lectura. Un número de versión es una cantidad que lógicamente * cambia con el tiempo * y, por lo tanto, no es * constante *. Solo use const para cosas que * nunca han cambiado, y nunca cambiarán *, como el valor de pi o el número atómico de plomo. –
Sólo lectura hace mucho sentido en situaciones donde se pasa una referencia de servicio a través del constructor, es decir
public class MyViewModel { private readonly MyContext context; public MyViewModel(MyContext context) { this.context = context; } }
es obvio que no quiere que su contexto sobrescrito con otro, porque puede tener muchas cosas dependientes de ese servicio en particular dentro de la clase. Y si se trata de un parámetro de constructor, eso generalmente significa que confía en ese servicio u objeto en particular para crear y mantener el estado válido del objeto. Así que solo es un buen indicador de eso. Tener un conjunto privado en la propiedad significa que no puede cambiarlo fuera de la clase, solo es una restricción adicional que hace las cosas un poco más seguras y comprensibles.
Gracias por todos los comentarios. Continuaré y marcaré a mis miembros como de solo lectura. Aclamaciones. – Bobbo