c# - valid - ¿Son los miembros/campos protegidos realmente tan malos?

summary param name c#

Question

Ahora, si lee las convenciones de nomenclatura en MSDN para C #, notará que indica que las propiedades siempre se prefieren a los campos públicos y protegidos. Algunas personas incluso me han dicho que nunca debes usar campos públicos o protegidos. Ahora estoy de acuerdo en que todavía tengo que encontrar una razón por la cual necesito tener un campo público, ¿pero los campos protegidos son realmente tan malos?

Puedo verlo si necesita asegurarse de que se realicen ciertas comprobaciones de validación al obtener / establecer el valor, sin embargo, muchas veces, en mi opinión, parece una sobrecarga adicional. Quiero decir, digamos que tengo una clase GameItem con campos para BaseName, prefixName y suffixName. ¿Por qué debería tomar la sobrecarga de crear tanto las propiedades ( C# ) o los métodos de acceso y el impacto de rendimiento que ocurriría (si hago esto para cada campo en una aplicación, estoy seguro de que se agregará un poco especialmente) en ciertos lenguajes como PHP o ciertas aplicaciones con rendimiento es crítico como los juegos)?

Answer 1

¿Son los miembros / campos protegidos realmente tan malos?

No. Son mucho, mucho peor.

Tan pronto como un miembro es más accesible que private , está garantizando a otras clases cómo se comportará ese miembro. Dado que un campo no está totalmente controlado, ponerlo "en libertad" abre su clase y las clases que heredan o interactúan con su clase a un mayor riesgo de errores. No hay forma de saber cuándo cambia un campo, no hay forma de controlar quién o qué lo cambia.

Si ahora, o en algún momento en el futuro, cualquiera de su código alguna vez depende de un campo de cierto valor, ahora tiene que agregar verificaciones de validez y lógica de respaldo en caso de que no sea el valor esperado, en cualquier lugar donde lo use. Eso es una gran cantidad de esfuerzo desperdiciado cuando podrías haberlo convertido en una maldita propiedad en su lugar;)

La mejor manera de compartir información con las clases derivadas es la propiedad de solo lectura :

protected object MyProperty { get; }

Si absolutamente tienes que hacerlo leer / escribir, no lo hagas. Si realmente tienes que hacerlo de lectura / escritura, replantea tu diseño. Si todavía lo necesita para leer y escribir, discúlpese con sus colegas y no lo haga de nuevo :)

Muchos desarrolladores creen, y le dirán, que esto es demasiado estricto. Y es cierto que puedes arreglártelas sin ser tan estricto. Sin embargo, adoptar este enfoque lo ayudará a pasar de ser un software extraordinariamente robusto. Pasarás mucho menos tiempo arreglando errores.

Y con respecto a cualquier preocupación sobre el rendimiento, no lo haga. Le garantizo que nunca, en toda su carrera, escribirá un código tan rápido que el cuello de botella sea la propia pila de llamadas.

Answer 2

Con respecto a los campos frente a las propiedades, se me ocurren dos razones para preferir las propiedades en la interfaz pública (protegido también es público en el sentido de que alguien más que su clase puede verlo).

• La exposición de propiedades le da una forma de ocultar la implementación. También le permite cambiar la implementación sin cambiar el código que la usa (por ejemplo, si decide cambiar la forma en que se almacenan los datos en la clase)

• Muchas herramientas que trabajan con clases que utilizan la reflexión solo se centran en las propiedades (por ejemplo, creo que algunas bibliotecas para la serialización funcionan de esta manera). El uso constante de las propiedades facilita el uso de estas herramientas estándar de .NET.

Respecto a los gastos generales:

• Si el getter / setter es el código de una línea habitual que simplemente lee / establece el valor de un campo, entonces el JIT debería poder integrar la llamada, de modo que no se haya superado el rendimiento.

• La sobrecarga sintáctica se reduce en gran medida cuando se usan propiedades implementadas automáticamente (C # 3.0 y más nuevas), por lo que no creo que esto sea un problema:

  protected int SomeProperty { get; set; }

  De hecho, esto le permite hacer, por ejemplo set proteger y get público muy fácilmente, por lo que puede ser incluso más elegante que usar campos.

Answer 3

En realidad, depende de si su clase es una clase de datos o una clase de comportamiento.

Si mantiene su comportamiento y sus datos separados , está bien exponer los datos de sus clases de datos, siempre y cuando no tengan ningún comportamiento.

Si la clase es una clase de comportamiento, entonces no debería exponer ningún dato.

Answer 4

Estoy de acuerdo con la respuesta de propiedad de solo lectura. Pero para jugar al abogado del diablo aquí, realmente depende de lo que estés haciendo. Estaré encantado de admitir que escribo código con miembros públicos todo el tiempo (tampoco hago comentarios, sigo las pautas o cualquiera de las formalidades).

Pero cuando estoy en el trabajo, es una historia diferente.

Answer 5

Los campos públicos y / o protegidos son malos porque se pueden manipular desde fuera de la clase declarante sin validación; por lo tanto, se puede decir que rompen el principio de encapsulación de la programación orientada a objetos.

Cuando pierdes la encapsulación, pierdes el contrato de la clase declarante; no se puede garantizar que la clase se comporte como se espera o se espera.

El uso de una propiedad o un método para acceder al campo le permite mantener la encapsulación y cumplir el contrato de la clase declarante.

Answer 6

OK, vota a la baja.

• En primer lugar, las propiedades nunca dañarán el rendimiento (siempre que no hagan mucho). Eso es lo que todos dicen, y estoy de acuerdo.

• Otro punto es que las propiedades son buenas porque puede colocar puntos de interrupción en ellas para capturar eventos de obtención / configuración y averiguar de dónde provienen.

El resto de los argumentos me molestan de esta manera:

• Suenan como "argumento por prestigio". Si MSDN lo dice, o algún desarrollador o autor famoso que le guste a todo el mundo lo dice, debe ser así.

• Se basan en la idea de que las estructuras de datos tienen muchos estados inconsistentes y deben protegerse contra el desplazamiento o la colocación en esos estados. Dado que (me parece a mí) las estructuras de datos están demasiado enfatizadas en la enseñanza actual, entonces típicamente necesitan esas protecciones. Mucho más preferible es minimizar la estructura de los datos para que se normalice y no tenga estados inconsistentes. Luego, si se cambia un miembro de una clase, simplemente se cambia, en lugar de dañar. Después de todo, de alguna manera, un montón de software bueno estaba escrito en C, y eso no sufrió masivamente por la falta de protecciones.

• Se basan en la codificación defensiva llevada a los extremos. Se basa en la idea de que tus clases se utilizarán en un mundo en el que no se puede confiar en el código de nadie más para que no pongas en marcha tus cosas. Estoy seguro de que hay situaciones en las que esto es cierto, pero nunca las he visto. Lo que he visto son situaciones en las que las cosas se hicieron horriblemente complicadas para sortear protecciones para las que no era necesario, y para tratar de proteger la consistencia de las estructuras de datos que eran terriblemente demasiado complicadas y no normalizadas.