variables públicas frente a las variables privadas con descriptores de acceso

Question

tiene cualquier persona personas lo demás visto hacer esto:

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

Entiendo que el uso de descriptores de acceso si se va a ejercer algún tipo de control sobre cómo se consigue el sistema o realizar algún tipo de función en él cuando hay un get. Pero si solo vas a hacer esto, ¿por qué no simplemente hacer que la variable sea pública para empezar? ¿Me estoy perdiendo de algo?

Answer 1

Si convierte al miembro en un campo público, no podrá refaccionarlo posteriormente en una propiedad sin cambiar la interfaz a tu clase. Si lo expone como una propiedad desde el principio, puede realizar los cambios necesarios en las funciones de acceso a la propiedad que necesita y la interfaz de la clase permanece inalterada.

Tenga en cuenta que a partir de C# 3.0, puede implementar una propiedad sin crear un campo de respaldo, p.:

public string Name { get; set; } 

Esto quita lo que es prácticamente la única justificación para no implementar campos públicos como propiedades en primer lugar.

Answer 2

Preparación. Nunca se sabe cuándo querrá eliminar el dispositivo de acceso configurado más adelante, realizar operaciones adicionales en el dispositivo o cambiar la fuente de datos para el servicio.

Answer 3

Los miembros de acceso público normalmente deben ser métodos y no campos. Es solo una buena práctica, y esa práctica te ayuda a asegurarte de que el estado encapsulado de tus objetos esté siempre bajo tu control.

Answer 4

La idea es que si utiliza accesadores, la implementación subyacente se puede cambiar sin cambiar la API. Por ejemplo, si decide que cuando establece el nombre, también necesita actualizar un cuadro de texto u otra variable, ninguno de los códigos de su cliente debería cambiar.

Answer 5

Si se define una interfaz pública con una propiedad en conjunto A, usted podría entonces utilizar esta interfaz en el montaje B.

Ahora, puede cambiar la aplicación de la propiedad (tal vez ir a buscar el valor de una base de datos en lugar de almacenar en un campo). Luego puede recompilar el ensamblaje A y reemplazar uno anterior. La Asamblea B continuaría bien porque la interfaz no habría cambiado.

Sin embargo, si inicialmente había comenzado con un campo público, y decidió que esto no era adecuado y quería cambiar la implementación y para hacer eso, necesitaba convertirlo a una propiedad, entonces esto significaría que ' d tiene que cambiar la interfaz pública de la Asamblea A. Todos los clientes de esa interfaz (incluido el ensamblado B) también deberían ser recompilados y reemplazados para poder trabajar con esta nueva interfaz.

Por lo tanto, es mejor comenzar con una propiedad inicialmente. Esto encapsula la implementación de la propiedad, permitiéndole cambiarla en el futuro sin tener que preocuparse de qué clientes (incluido el ensamblado B) ya están en el mundo utilizando el ensamblaje A. Porque, si ya hay clientes en el mundo haciendo uso del ensamblaje A, cambiar la interfaz rompería todos los clientes. Si otro equipo de su empresa u otra empresa los usa, ¡no van a estar contentos si rompe sus ensamblajes al cambiar su interfaz!

Answer 6

Buena práctica de programación. Este es un patrón muy común que se ajusta a las metodologías de diseño OO. Al exponer un campo público, expone los aspectos internos de cómo se almacenan esos datos. El uso de una propiedad pública le permite más flexibilidad para cambiar la forma en que los datos se almacenan internamente y no romper la interfaz pública. También le permite tener más control sobre lo que sucede cuando se accede a los datos (inicialización lenta, comprobaciones nulas, etc.)

Answer 7

Las variables forman parte de la implementación de una clase. Las propiedades más lógicamente representan la interfaz para ello. Con C# 3.0, las propiedades implementadas automáticamente hacen que esto sea muy fácil de hacer desde el principio.

He escrito más ideas sobre esto, incluidas las diversas formas en que el cambio de una variable a una propiedad no solo rompe la compatibilidad binaria, sino también la compatibilidad de la fuente, en an article on the topic.

Answer 8

Para el encapsulado, no se recomienda el uso de campos públicos.

http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks=0

Como dijo Chris Anderson más adelante en este libro, que sería lo ideal sería que la persona que llama ciegos a la diferencia de campo frente a la propiedad.

Answer 9

Para conservar un alto grado de extensibilidad sin el dolor de volver a compilar todos sus ensamblajes, desea utilizar propiedades públicas como accesos. Al seguir un "contrato" o un mecanismo definido que describa cómo sus objetos intercambiarán datos, se establecerá un conjunto de reglas. Este contrato se aplica con una interfaz y se cumple por los getters y setters de su clase que hereda esta interfaz.

Más adelante, si crea clases adicionales desde esa interfaz, tiene flexibilidad de cumplir el contrato con el uso de las propiedades, pero dado que está proporcionando los datos a través de los getters y setters, la implementación o el proceso de ensamblado datos puede hacer lo que quiera, siempre y cuando devuelva el tipo que el "contrato" espera.

Answer 10

Vale la pena señalar que DataBinding en .NET también se niega a trabajar en campos públicos y exige propiedades. Entonces esa podría ser otra razón.