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

Question

Estoy usando .NET 2.0, por lo que no tengo acceso a las propiedades automáticas. Por lo que debe recurrir a la siguiente forma de codificar las 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 que contiene los miembros privados/públicos por encima, hay alguna forma de restringir el acceso a la variable privada? No me gusta que pueda usar m_hello o Hello.

Gracias.

Answer 1

No, no hay una manera de hacer eso, aparte de 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 hay no debería ser un problema.

Answer 2

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

Se podría probablemente hacerlo con las herramientas, pero con el tiempo que tienen que confiar en la gente para no hacer cosas estúpidas. Después de todo, ¿tienes reglas especiales sobre: ​​

while(true) { } 

o simplemente lo pones en "no seas estúpido"? ; p

Answer 3

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 aplicar el estándar.

Answer 4

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.

Answer 5

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 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 decir a mí mismo: "OK, donde quiera que establece este valor dentro de esta clase, que debe utilizar Denominator para asegurarse de que No lo estoy poniendo a cero ". Pero estoy completamente en control de lo que estoy configurando Denominator - ¡Estoy dentro de la clase! En este escenario, el objetivo de la lógica en la propiedad 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 es no está mal para acceder a miembros privados dentro de una clase.

Answer 6

Esto se puede hacer 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 
} 

Answer 7

Si usted se encuentra el deseo de ocultar los detalles del mismo, que puede ser un olor código que su clase tiene demasiadas responsabilidades. Considere la posibilidad de extraer una de las responsabilidades en una nueva clase.

Answer 8

Como otros han sugerido que esta debe ser una respuesta ...

Puede seguir utilizando las propiedades automáticas en C# 3 cuando la orientación de .NET 2.0, junto con quite a few other C# 3 features. A diferencia de los árboles de expresiones (por ejemplo), las propiedades automáticas no necesitan nada especial del CLR o el marco, más allá del atributo [CompilerGenerated] (que se introdujo en .NET 2.0).

Si está utilizando VS2008 o VS2010, entonces valdría la pena utilizar una propiedad automática.

Por lo que vale la pena, me gustaría esta habilidad también. Me gustaría ser capaz de variables de ámbito 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 sólo lectura - no hace ninguna diferencia a los clientes, sino que ayuda a hacer cumplir la corrección dentro del código de la clase sí mismo.