2010-05-21 12 views
5

La encapsulación es obviamente útil y esencial cuando se accede a miembros externos a la clase, pero cuando se hace referencia a variables de clase internamente, ¿es mejor llamar a sus miembros privados o utilizar sus getters? Si su captador simplemente devuelve la variable, ¿hay alguna diferencia de rendimiento?¿Cuáles son los beneficios de usar propiedades internamente?

+1

trata de preguntarle a su auto esta pregunta: si cree que su propia declaración (que no veo ninguna razón para que no) "La encapsulación es obviamente útil y esencial cuando se accede a los miembros de fuera de la clase" y luego tratar de llegar con un argumento sólido sobre por qué las cosas deberían ser diferentes si eliminaste las últimas cuatro palabras. Si no puede saber que puede usar los mismos argumentos :) –

+0

@ChrisF: ese hilo no tiene ninguna relación con esta pregunta – fearofawhackplanet

+0

Se eliminó el enlace a lo que resultó ser una pregunta irrelevante. – ChrisF

Respuesta

9

No debe haber una diferencia de rendimiento significativa, y la razón por la que se adhiere al uso de las propiedades es porque ese es el objetivo de la encapsulación. Mantiene todos los accesos de esos miembros privados consistentes y controlados. Entonces, si desea cambiar el getter/setter de la propiedad, no tiene que pensar "¿necesito duplicar la misma funcionalidad en otros lugares en los que decidí acceder directamente al miembro privado?"

4

El beneficio sería en los casos en que hubo validación para hacerse en el Get o Set. Esto sería en un lugar y siempre llamado.

Hasta donde yo sé (por otras preguntas formuladas en Stack Overflow) cuando Getter simplemente devuelve el valor, el código generado es el mismo que para acceder a la variable directamente.

7

Acceder al campo directamente o usar el captador generalmente no hace una gran diferencia, a menos que su captador realice una inicialización diferida u otro procesamiento. Entonces depende de lo que hace el captador, pero mi regla de oro es usar siempre el captador, excepto en casos específicos.

Para asignar un valor al campo, no olvide que los instaladores suelen incluir código de validación o plantear un evento. En ese caso, siempre debes usar setter.

+1

+1: Esta es una buena regla empírica. Hay una tendencia general a usar el miembro privado .. "No estoy haciendo nada en el getter y/o setter ... sería un desperdicio llamar a un método ... Haré una tarea ... cool " (culpable ... lo admito) Luego, más tarde tú, o peor alguien más, le agregas algo de validación al colocador y ... golpe ... tu objetivo es quien disparó a la reunión del conejito. Como dijo Thomas ... siempre hay espacio para una exención de caso especial ... por hábito use el colocador. – Rusty

+0

De todos modos, los getters o setters simples suelen estar integrados por el compilador JIT, por lo que ni siquiera es una optimización para acceder al campo directamente ... –

1

La diferencia de rendimiento es insignificante, en aproximadamente el 98% del tiempo.

Siempre debe usar propiedades aunque su captador o instalador solo obtenga o configure su miembro privado. Esto le permitirá traer cambios a medida que su aplicación evolucione. Al hacerlo, podrá traer algunas restricciones u otra encapsulación dentro de sus propiedades sin romper su código. De lo contrario, una vez que decida escribir propiedades por un motivo X, se verá obligado a refactorizar todo su código para obtener o establecer la propiedad en lugar de su miembro privado.

1

Me gusta usar propiedades internas para la inicialización lenta, donde en la propiedad se asegura de que el objeto se inicialice. Esto asegura que no estoy usando variables de nivel de clase que aún no se han inicializado.

TestClass1 _class1 
internal TestClass1 
{ 

get 
{ 

    if (_class == null) 
    _class = new TestClass1() 

    return _class1 

} 

} 
Cuestiones relacionadas