what - ¿Por qué nadie aceptará campos públicos en C#?

property c#

Question

Parece que cada analizador estático de C # quiere quejarse cuando ve un campo público. ¿Pero por qué? Seguramente hay casos en que un campo público (o interno) es suficiente, y no tiene sentido tener una propiedad con sus métodos get_ y set_ ? ¿Qué pasa si sé con certeza que no redefiniré el campo ni lo agregaré (los efectos secundarios son malos, ¿no?) - ¿no bastaría un campo simple?

Answer 1

Creo que el punto es que, en general, no está seguro de que no redefina el campo o lo agregue más adelante. El objetivo de encapsular y ocultar los datos es que usted es libre de hacer estas cosas sin cambiar la interfaz pública y posteriormente romper las clases dependientes. Si los descriptores de acceso a sus propiedades son simplemente conjuntos / conjuntos simples, entonces se compilarán de ese modo, por lo que no hay problemas de rendimiento, dado que su pregunta debería ser si hay alguna buena razón para no utilizarlos.

Answer 2

Dado el hecho de que la C # 3.0 actual permite propiedades automáticas cuya sintaxis es similar a la siguiente:

public int Property {get; set;}

el trabajo adicional requerido para usar Propiedades en campos públicos es casi cero. La cuestión es que nunca se puede estar completamente seguro de que un campo no se usará de manera diferente o que el descriptor de acceso no cambiará nunca y, dado el intercambio en el trabajo, no hay ninguna razón para no implementar una propiedad.

De todos modos, el analizador se queja de cosas que en un alto porcentaje (en este caso, como el 99,99% de los casos) son malas prácticas de programación ... pero de todos modos solo se está quejando. Los campos pueden hacerse públicos y hay algunos casos extremos en los que su uso directo puede estar justificado. Como siempre, use su sentido común ... pero tenga en cuenta la regla elemental para las mejores prácticas de programación ... ¿Hay realmente una buena razón para romper la convención? Si sigue adelante, si no es así o si la respuesta es "implica más trabajo", entonces adhiérase a la práctica ...

Answer 3

Debido a que cambiar los campos públicos más tarde para tener accesadores get / set se romperá el código. Vea esta respuesta para más información

Answer 4

Debido a que rompe la encapsulación, esta es la razón por la cual la mayoría de las personas usan los accesos de forma intensiva. Sin embargo, si cree que es la solución adecuada para su tarea, ignórela (es decir, las quejas estrictas de encapsulación) y haga lo correcto para su proyecto. No dejes que los OO nazis te digan lo contrario.

Answer 5

En general, es una buena idea ocultar los campos detrás de las propiedades, incluso si "sabes con certeza" que no vas a redefinir el campo. Con demasiada frecuencia, lo que "sabes con certeza" hoy cambia mañana. Y, hacer una propiedad para referirse a un campo es solo un pequeño problema.

Dicho esto, los analizadores estáticos no son un sustituto del pensamiento. Si está contento con su diseño y, a su juicio, el analizador está equivocado, entonces ignore o (si es posible) suprima esa advertencia en esa circunstancia.

Answer 6

Otra de las propiedades de beneficios que trae a la mesa es cuando se hace Reflection. Cuando reflexiona sobre su clase, puede obtener todas las propiedades de una vez, en lugar de tener que obtener las propiedades Y los campos.

Answer 7

Realmente se trata de proteger tu código a futuro. Cuando dices (énfasis mío):

¿Qué pasa si sé con certeza que no redefiniré el campo ni lo agregaré (los efectos secundarios son malos, ¿no?) - ¿no bastaría un campo simple?

Esa es una declaración absoluta, y como sabemos (al igual que la mayoría de los analizadores estáticos), solo hay dos absolutos en la vida.

Solo trata de protegerte de eso. Si es un problema, debe poder decirle al analizador que lo ignore (a través de atributos que dependen de la herramienta de análisis que esté usando).

Answer 8

Y no olvidemos que los accesadores le dan flexibilidad al trabajar con múltiples hilos.