¿Está utilizando las propiedades get set de C# como una buena práctica?

Question

mi pregunta es simple, ¿está utilizando las propiedades get set de C# consideradas buenas, incluso mejor que escribir métodos getter y setter? Cuando utiliza estas propiedades, ¿no tiene que declarar a los miembros de sus datos de clase como públicos? Pregunto esto porque mi profesor declaró que los miembros de los datos deberían nunca declararse como públicos, ya que se considera una mala práctica.

Este ....

class GetSetExample 
{ 
    public int someInt { get; set; } 
} 

vs Este ...

class NonGetSetExample 
{ 
    private int someInt; 
} 

Editar:

Gracias a todos ustedes! Todas sus respuestas me ayudaron y voté correctamente sus respuestas.

Answer 1

Este:

class GetSetExample 
{ 
    public int someInt { get; set; } 
} 

es realmente lo mismo que esto:

class GetSetExample 
{ 
    private int _someInt; 
    public int someInt { 
     get { return _someInt; } 
     set { _someInt = value; } 
    } 
} 

La sintaxis get; set; es sólo un atajo conveniente para este que se puede utilizar cuando el getter y setter no hacen algo especial.

Por lo tanto, no está exponiendo a un miembro público, está definiendo un miembro privado y proporcionando métodos get/set para acceder a él.

Answer 2

En su primer ejemplo, C# genera automáticamente los campos de respaldo privados, por lo que técnicamente el miembro de datos no se declara como público solo el getter/setter.

Answer 3

Es bastante razonable, y su profesor (sin contexto) está equivocado. Pero de todos modos, usar "propiedades automáticas" está bien, y puedes hacerlo ya sea que sean públicas o privadas.

Aunque en mi experiencia, cada vez que uso uno, casi inevitablemente necesito escribir algo de lógica allí, y por lo tanto no puedo usar los accesorios automáticos.

Answer 4

Sí, los miembros normalmente nunca deben declararse públicos en buen diseño por varias razones. Piensa en OOP donde heredas la clase más tarde. Algo difícil de anular en un campo. :-) También le impide mantener sus internos a los que se accede directamente.

The simplistic get; conjunto; el diseño se introdujo en C# 2.0. Básicamente es lo mismo que declarar todo con un miembro privado que lo respalda (descompílelo en una herramienta como Reflector y vea).

public int someInt{get;set;} 

es directamente iguales a los

private int m_someInt; 
public int someInt{ 
    get { return m_someInt; } 
    set { m_someInt = value; } 
} 

La gran parte de tener el simplificada captador/definidor es que cuando se desea llenar en la ejecución con un poco más agallas posterior, no se rompen Compatibilidad ABI

No se preocupe si getter/setters ralentiza su código indirectamente. El JIT tiene una cosa llamada inlineing que hace que usar el getter/setter sea tan eficiente como el acceso directo al campo.

Answer 5

En un enfoque orientado a objetos "puro", no se considera correcto exponer el estado de los objetos, y esto se aplica a las propiedades tal como se implementan en .NET y get_set_properteis de Java/EJB. La idea es que al exponer el estado de su objeto, está creando dependencias externas a la representación de datos internos de su objeto. Un diseño de objeto puro reduce todas las interacciones a mensajes con parámetros.

De vuelta al mundo real: si tratas de implementar un enfoque teórico tan estricto en el trabajo, o te reirán de la oficina o te harán pedazos. Las propiedades son inmensamente populares porque son un compromiso razonable entre un diseño de objeto puro y datos privados completamente expuestos.

Answer 6

Sí. Los miembros de los datos deben ser privados y las propiedades automáticas lo permiten y otorgan acceso público en el camino correcto.

Pero debe tener cuidado. Comprenda que el contexto es muy importante. En la aplicación con subprocesos, actualizar una propiedad después de otra propiedad relacionada puede ser perjudicial para la coherencia. En ese caso, un método setter que actualice los dos miembros de datos privados de forma adecuada tiene más sentido.

Answer 7

su profesor tenía toda la razón.

Considere este ejemplo trivial de por qué "captadores" deben evitarse: Puede haber 1.000 llamadas a un método getX() en su programa, y ​​cada una de esas llamadas supone que el valor de retorno es un tipo particular. El valor de retorno de getX() se puede ordenar en una variable local, por ejemplo, y el tipo de variable debe coincidir con el tipo de valor de retorno. Si necesita cambiar la forma en que se implementa el objeto de tal manera que cambie el tipo de X, tendrá un problema grave. Si X solía ser un int, pero ahora tiene que ser un long, ahora obtendrá 1,000 errores de compilación. Si soluciona el problema incorrectamente al convertir el valor devuelto a int, el código se compilará limpiamente pero no funcionará. (El valor de retorno puede verse truncado.) Debe modificar el código que rodea cada una de esas 1,000 llamadas para compensar el cambio. Yo, al menos, no quiero hacer tanto trabajo.

Holub On Patterns

Answer 8

porque con el miembro de datos públicos, que el miembro de datos se puede cambiar o puede ser leído fuera de clase y no se puede controlar de lectura/escritura accesibilidad operación, pero con propiedades que se pueden controlar de lectura/escritura corriente, por ejemplo, tener en cuenta esta declaración:

public MyVar{private get; public set;} 

significa valor de MyVar sólo puede cambiarse dentro de la clase y se puede leer fuera de clase (léase privada y leer públicamente) y esto no es p posible con sólo miembros de datos públicos