Están protegidos los miembros / campos realmente tan malo?

Question

Ahora bien, si usted lee las convenciones de nombres en el MSDN para C # se puede observar que se afirma que las propiedades son siempre preferibles a los campos públicos y protegidos. Incluso me han dicho algunas personas que nunca se debe utilizar campos públicos o protegidos. Ahora estoy de acuerdo todavía tengo que encontrar una razón en la que tengo que tener un campo público, pero son campos protegidos realmente tan malo?

Me lo puede ver si usted necesita para asegurarse de que ciertas comprobaciones de validación se realizan cuando obtener / establecer el valor sin embargo, una gran parte del tiempo parece que fue adicional por encima en mi opinión. Me refiero Digamos que tengo una clase con GameItem campos para baseName, prefixName y suffixName. ¿Por qué debería tener la sobrecarga de tanto la creación de las propiedades (C#) o métodos de acceso y el impacto en el rendimiento que tendrían lugar (si hago esto para cada campo individual en una aplicación, estoy seguro de que lo haría suma al menos un poco de todo en ciertos lenguajes como PHP o ciertas aplicaciones con el rendimiento es crítico, como los juegos)?

Answer 1

Están protegidos los miembros / campos realmente tan malo?

n. Son muy, muy mal.

Tan pronto como un miembro es más accesible que private, usted está haciendo garantías a otras clases de cómo se comportará ese miembro. Dado que un campo es totalmente incontrolada, poniendo "en el medio silvestre" abre su clase y clases que heredan de o interactuar con su clase a un mayor riesgo de errores. No hay manera de saber cuando un campo cambia, no hay manera de controlar quién o qué cambios.

Si ahora, o en algún momento en el futuro, cualquiera de su código cada vez depende de un campo poco de cierto valor, que ahora tienen que añadir las comprobaciones de validez y la lógica alternativa en caso de que no es el valor esperado - cada lugar que lo utilice . Eso es una gran cantidad de desperdicio de esfuerzo cuando usted podría haber sólo lo hizo una propiedad maldita vez;)

La mejor manera de compartir información con las clases derivadas es el propiedad de sólo lectura

protected object MyProperty { get; }

Si es absolutamente Tienes para que sea de lectura / escritura, no lo hacen. Si realmente, realmente tiene que hacerlo de lectura y escritura, reconsiderar su diseño. Si todavía necesita que sea de lectura y escritura, pedir perdón a sus compañeros y no hacerlo de nuevo:)

Una gran cantidad de desarrolladores creen - y le dirá - que esto es demasiado estricta. Y es cierto que se puede arreglárselas muy bien, sin ser esta estricta. Sin embargo, este enfoque le ayudará a ir desde apenas de pasar a un software muy robusto. Vas a pasar mucho menos tiempo corrigiendo errores.

Y con respecto a cualquier preocupación sobre el rendimiento - no lo hacen. Te garantizo que nunca, en toda su carrera, código de escritura tan rápido que el cuello de botella es la pila de llamadas en sí.

Answer 2

OK, el tiempo downvote.

• En primer lugar, las propiedades serán el rendimiento no le hace mal (siempre que no hacen mucho). Eso es lo que todos dicen, y estoy de acuerdo.

• Otro punto es que las propiedades son buenas en el que se puede colocar puntos de interrupción en ellos para la captura de obtener / establecer eventos y averiguar de dónde vienen.

El resto de los argumentos me molesta de esta manera:

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

• Se basan en la idea de que las estructuras de datos tienen una gran cantidad de estados inconsistentes, y deben ser protegidos contra errante o de ser colocado en esos estados. Puesto que (me parece) estructuras de datos se forma sobre-enfatizadas en la enseñanza actual, entonces típicamente DO necesitan esas protecciones. Mucho más preferible es minimizar estructura de datos de modo que tiende a ser normalizado y no tener estados inconsistentes. Entonces, si se cambia un miembro de una clase, simplemente se cambió, en vez de dañado. Después de todo, de alguna manera un montón de buen software era / es escrito en C, y que no sufrieron enormemente por la falta de protecciones.

• Se basan en la defensiva codificación se lleva al extremo. Se basa en la idea de que las clases serán utilizados en un mundo donde el código de nadie más puede confiar en que no ganso tus cosas. Estoy seguro de que hay situaciones en que esto sea cierto, pero He no los ve. Lo que Tienes ve es situaciones donde las cosas se hicieron terriblemente complicado de conseguir alrededor de las protecciones para las que no había necesidad, y para tratar de proteger la consistencia de las estructuras de datos que fueron horriblemente complicado en off y normalizado por la ONU .

Answer 3

En cuanto a los campos frente a propiedades, se me ocurren dos razones para preferir propiedades en la interfaz pública (protegida también es pública, en el sentido de que alguien más que sólo su clase puede verlo).

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

• Muchas de las herramientas que el trabajo con las clases que utilizan la reflexión sólo se centran en las propiedades (por ejemplo, creo que algunas bibliotecas para el trabajo de serialización de esta manera). El uso de propiedades hace consistentemente más fácil de usar estas herramientas .NET estándar.

En cuanto a los gastos generales:

• Si el captador / definidor es la pieza de la línea habitual de código que simplemente lee / establece el valor de un campo, entonces el JIT debe ser capaz de inline la llamada, así que no hay overhad rendimiento.

• sintáctico sobrecarga se reduce en gran medida cuando se está utilizando propiedades implementadas automáticamente (C # 3.0 y posteriores), así que no creo que esto es un problema:

  protected int SomeProperty { get; set; }
  

  De hecho, esto le permite hacer, por ejemplo, set protegido y público get muy fácilmente, por lo que este puede ser aún más elegante que el uso de campos.

Answer 4

Pública y / o campos protegidos son malas, ya que pueden ser manipulados desde fuera de la clase que se declara sin validación; por lo tanto se puede decir para romper el principio de encapsulación de la programación orientada a objetos.

Cuando se pierde la encapsulación, se pierde el contrato de la clase que declara; no se puede garantizar que se comporta de clase según lo previsto o esperado.

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

Answer 5

Estoy de acuerdo con la respuesta propiedad de sólo lectura. Pero hacer de abogado del diablo aquí, que realmente depende de lo que está haciendo. Estaré feliz de admitir que escribir código con los miembros del público todo el tiempo (tampoco me comentario, siguen las normas generales, o cualquiera de los trámites).

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

Answer 6

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

Si mantener su comportamiento y datos separado , está bien para exponer los datos de sus datos clases, siempre y cuando no tienen ningún comportamiento.

Si la clase es una clase de comportamiento, entonces no debe exponer todos los datos.