¿Bloquea el acceso a las variables de miembros privados? ¿Forzar el uso de propiedades públicas?

Estoy usando .NET 2.0, por lo que no tengo acceso a las propiedades automáticas. Así que debo recurrir a la siguiente forma de encoding de variables privadas y propiedades públicas

private string m_hello = null; public string Hello { get{return m_hello;} set{m_hello = value;} } 

Para los métodos de la clase contenedora de los miembros privados / públicos anteriores, ¿hay alguna forma de restringir el acceso a la variable privada? No me gusta que pueda usar m_hello o Hello.

Gracias.

No, no hay una manera de hacerlo, que no sea simplemente seguir su propia convención y hacer esto. Hola, si realmente necesita pasar por su propiedad pública.

No veo por qué necesitarías o querría hacer esto tampoco, ya que como es tu clase interna, tú eres el que tiene el control del código y puedes definir qué / cómo se usa, por lo que no debería haber un problema.

Como otros han sugerido, esta debería ser una respuesta …

Todavía puede usar propiedades automáticas en C # 3 cuando se dirige a .NET 2.0, junto con algunas otras características de C # 3 . A diferencia de los árboles de expresión (por ejemplo), las propiedades automáticas no necesitan nada especial del CLR o del marco, más allá del atributo [CompilerGenerated] (que se introdujo en .NET 2.0).

Entonces, si está usando VS2008 o VS2010, entonces valdría la pena usar una propiedad automática.

Por lo que vale, también me gustaría esta habilidad. Me gustaría poder hacer un scope variables dentro de una propiedad:

  public string Name { private string name; get { return name; } set { name = value; } } 

Veo esto un poco como hacer una variable privada de solo lectura; no hace ninguna diferencia para los clientes, pero ayuda a imponer la corrección dentro del código de clase.

Puedes lograr esto a través de la herencia:

 abstract class A // A is not instantiatable due to being abstract { private string m_hello = null; public string Hello { get{return m_hello;} set{m_hello = value;} } } class B : A { // B now cannot access the private variable, use B in your code instead of A } 

No estoy afirmando que esto sea bueno. Solo que se puede hacer.

No. Cualquier método dentro de la clase tendrá acceso a ambos.

Su equipo debe estandarizar el uso (propiedad o variable privada).

Una vez que decida cuál usar, podría intentar usar una regla FxCop personalizada para hacer cumplir el estándar.

No, básicamente. Bueno, podrías hacer algo con las advertencias del comstackdor a través de [Obsolete] y #pragma , pero eso sería excesivo.

Probablemente puedas hacerlo con herramientas, pero finalmente debes confiar en que la gente no haga cosas estúpidas. Después de todo, ¿tienes reglas especiales sobre:

 while(true) { } 

¿o simplemente lo dejas para “no seas estúpido”? ;pag

Solo debe acceder a la propiedad a través de la propiedad pública Hello. Esta es la razón de este patrón. Si agrega alguna funcionalidad al get o al set, si está accediendo a la instancia privada, introducirá errores en su código. Pero el error es NO, no puedes evitar que alguien llame al Privado cuando están dentro de tu clase cambiando tu código.

Personalmente, no veo nada de malo en acceder al miembro privado dentro de la clase. De hecho, eso es lo que normalmente hago (a menos que exista una lógica dentro de la propiedad getter / setter que siempre quiero aprovechar).

Simplemente tiene sentido para mí: el código dentro de la clase constituye la implementación de esa clase; ¿Por qué ocultar una implementación de sí mismo?

Aquí hay un ejemplo de lo que quiero decir. Supongamos que tengo algún miembro, m_denominator , y quiero que nunca sea cero:

 private int m_denominator = 1; public int Denominator { get { return m_denominator; } set { if (value == 0) throw new ArgumentException("Denominator must not be zero."); m_denominator = value; } } 

Podría decirme a mí mismo: “OK, donde quiera que establezca este valor dentro de esta clase, debería usar Denominator para asegurarme de que no lo ajuste a cero”. Pero estoy completamente en control de lo que voy a configurar Denominator – ¡Estoy dentro de la clase! En este escenario, el punto de la lógica en la propiedad del Denominator es proteger la clase de los valores no válidos establecidos por el código del cliente. No hay excusa para establecer su estado interno a algún valor no válido dentro de la implementación de una clase.

Por supuesto, esta no es una regla absoluta. Seguramente hay momentos en que usar la propiedad por su lógica dentro de una clase puede ser una elección sensata como medida de protección; Realmente, solo estoy argumentando que no está mal acceder a miembros privados dentro de una clase.

Si desea ocultar detalles de usted mismo, puede ser un olor a código que su clase tiene demasiadas responsabilidades. Considere la posibilidad de extraer una de las responsabilidades en una nueva clase.