Mejores prácticas sobre uso local de campo privado x propiedad

StackOverflow https://stackoverflow.com/questions/833047

Pregunta

Cuando dentro de una clase tienes un campo privado y expones ese campo en una propiedad pública, ¿cuál debo usar desde dentro de la clase?

Debajo de usted hay un ejemplo de lo que estoy tratando de averiguar. ¿Debe manioulate el campo privado _Contador o el contador de propiedades?

Prueba de clase pública 

Private _Counter As Integer

Public Property Counter() As Integer
    Get
        Return _Counter
    End Get
    Set(ByVal value As Integer)
        _Counter = value
    End Set
End Property

Private Sub Dosomething()

    'What is the best practice?
    'Direct access to private field or property?

    'On SET
    _Counter += 1
    'OR
    Me.Counter += 1

    'On Get
    Console.WriteLine(_Counter)
    Console.WriteLine(Me.Counter)

End Sub

Finalizar clase

Gracias de antemano por la ayuda. Edu

¿Fue útil?

Solución

En mi opinión, el uso interno de un descriptor público es una sobreencapsulación: difumina el código. Con este enfoque, las operaciones simples invocan accesores que pueden contener una lógica más compleja, por lo que es más difícil analizar el código de las operaciones.

En mi experiencia de programación, rara vez he tenido una situación en la que ayudaría mucho. En cambio, prefiero acceder a los campos directamente, y solo si es realmente necesario, para abstraer el acceso creando un acceso privado , que puede ser usado tanto por el acceso público como por otras funciones. La razón es que si necesita adjuntar alguna lógica especial en el descriptor de acceso público, es probable que la lógica no sea la misma para el acceso interno.

Tenga en cuenta también que los IDE más modernos (como Eclipse) permiten ver de inmediato todas las referencias a un campo privado y refactorizar el código para usar una función en lugar de un acceso directo.

Otros consejos

En mi opinión, debe utilizar el Accesor de propiedad siempre que sea posible. Esto se debe a que no tiene que preocuparse por ninguna lógica interna que pueda estar disponible cuando tiene una propiedad.

Un buen ejemplo de dónde sucede esto es en el código detrás de un Linq DataContext.

mira esto ... 

[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
    get
    {
        return this._ReviewType;
    }
    set
    {
        if ((this._ReviewType != value))
        {
            this.OnReviewTypeChanging(value);
            this.SendPropertyChanging();
            this._ReviewType = value;
            this.SendPropertyChanged("ReviewType");
            this.OnReviewTypeChanged();
        }
    }
}

¿Ves toda esa lógica en el 'setter'?

Es por eso que es importante comenzar a practicar la práctica de llamar a sus Propiedades en lugar de campos, IMO.

Gracias a todos por las respuestas y sugerencias.

Después de considerar todas las sugerencias aquí más otras investigaciones, tengo la impresión de que para esta situación en el campo privado versus el asesor es más una elección personal. Básicamente, lo más importante es que, sin importar lo que elija, sea consistente.

Dicho eso; mi regla personal se inclina hacia esto:

  1. Acceda a sus campos privados directamente.

  2. Si accede a los accesos, use la palabra clave ME. para mejorar la legibilidad

  3. Use el descriptor de acceso solo si implementa una lógica lógica vital que también se aplica al acceso privado. De esta manera, sabrá que si está utilizando el descriptor de acceso es porque hay "algo más" en él "

  4. Evite usar campos protegidos. Las clases derivadas siempre deben usar el descriptor de acceso, nunca el acceso directo al campo.

Déjame saber lo que piensas.

Nota al margen:

Después de esto, creo que nos falta un nuevo alcance para los campos de nivel de clase. Una palabra clave como & # 8220; Restringida & # 8221; donde solo se puede acceder a este campo desde su getter / setter. De esta manera, siempre accede directamente a los campos privados, pero si necesita asegurarse de que su acceso solo puede acceder a ciertos campos, cambie el campo Privado a Restringido. (¿qué tal "Restricted, RestrictedRead y RestrictedWrite " ;?)

Prefiero usar la propiedad siempre que sea posible. Esto le brinda la flexibilidad en el futuro para modificar lo que devuelve / establece la propiedad sin tener que pasar y encontrar todas las ubicaciones que estaban usando la variable privada.

Use el campo privado porque no está haciendo algo específico en el setter.

También recomendaría eliminar el configurador de propiedades, de esta forma obligará al estado del contador a establecerse mediante el método DoSomething ()

Dependiendo de la situación, puede ser preferible permitir la modificación directa de un campo en una clase solo de forma privada, o mediante algún método que asocie la semántica con la modificación. De esta manera, es más fácil razonar sobre esta clase y ese valor en particular, ya que puede estar seguro de que solo se modifica de cierta manera. Además, en algún momento, una acción como incrementar e int puede tener consecuencias adicionales requeridas, en cuyo punto tiene más sentido exponer el acceso a ella a través de métodos.

Yo siempre uso los accesos de propiedad, porque estoy seguro en caso de que agregue lógica en el captador o definidor en el futuro, sabiendo con seguridad que ningún código lo omite.

Si le preocupa la sobrecarga de rendimiento de llamar a los accesos de propiedad cuando simplemente van directamente al campo, no lo haga. La mayoría de los compiladores incluirán este tipo de cosas, dándole efectivamente el mismo rendimiento. Al menos, es poco probable que necesite los nanosegundos de tiempo adicionales que podría ganar yendo directamente al campo.

Es mejor seguir con los accesores de propiedades porque a) puede ser muy consistente en todo su código, lo que lo hace más fácil de mantener yb) obtiene los beneficios señalados por otros aquí.

Además, generalmente no agrego las palabras clave Me. (o this. ), a menos que haya un problema de alcance (que trato de evitar eligiendo mis identificadores cuidadosamente). Esto no me confunde porque mis funciones y subs nunca son tan largos que no estoy seguro de si estoy trabajando con una variable local (basada en la pila) o un miembro de la clase. Cuando tardan demasiado en decirlo fácilmente, refactorizo.

El póster original es EXACTAMENTE correcto.

1) Acceda a sus campos privados directamente.

  • Facilita la refactorización.

2) Si accede a los accesos, use la palabra clave ME. para mejorar la legibilidad

  • enumerar explícitamente el alcance requiere menos reflexión por parte del lector

3) Use el descriptor de acceso solo si implementa una lógica lógica vital que también se aplica al acceso privado. De esta manera, sabrá que si está utilizando el descriptor de acceso es porque hay & # 8220; algo más & # 8221;

  • esta es la única razón para violar la regla # 1.

4) Evite el uso de campos protegidos. Las clases derivadas siempre deben usar el descriptor de acceso, nunca el acceso directo al campo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top