¿Los miembros/campos protegidos son realmente tan malos?
Ahora, si lee las convenciones de nombres en MSDN para C#, notará que indica que las propiedades siempre son preferidas sobre los campos públicos y protegidos. Algunas personas incluso me han dicho que nunca debe usar campos públicos o protegidos. Ahora estoy de acuerdo en que todavía tengo que encontrar una razón en la que necesito tener un campo público, pero ¿los campos protegidos son realmente tan malos?
Puedo verlo si necesita asegurarse de que ciertas comprobaciones de validación se realizan cuando obtener / establecer el valor, sin embargo, la mayor parte del tiempo parece solo una sobrecarga adicional en mi opinión. Quiero decir, digamos que tengo una clase GameItem con campos para baseName, prefixName y suffixName. ¿Por qué debería tomar la sobrecarga de crear las propiedades (C#) o los métodos de acceso y el golpe de rendimiento que ocurriría (si hago esto para cada campo en una aplicación, estoy seguro de que se sumaría a menos un poco, especialmente en ciertos idiomas como PHP o ciertas aplicaciones con el rendimiento es crítico como los juegos)?
6 answers
¿Los miembros/campos protegidos son realmente tan malos?
No. Son mucho, mucho peores.
Tan pronto como un miembro es más accesible que private, está haciendo garantías a otras clases sobre cómo se comportará ese miembro. Dado que un campo está totalmente descontrolado, ponerlo "en la naturaleza" abre su clase y las clases que heredan o interactúan con su clase a un mayor riesgo de error. No hay manera de saber cuándo cambia un campo, no hay manera 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 cierto valor, ahora tiene que agregar comprobaciones de validez y lógica de reserva en caso de que no sea el valor esperado, en cada lugar que lo use. Eso es una gran cantidad de esfuerzo desperdiciado cuando podrías haberlo convertido en una maldita propiedad en su lugar;)
La mejor forma de compartir información con clases derivadas es la propiedad de solo lectura :
protected object MyProperty { get; }
Si usted absolutamente tiene para hacerlo de lectura/escritura, no. Si realmente, realmente tiene que hacerlo de lectura-escritura, reconsidere su diseño. Si aún lo necesitas para leer y escribir, discúlpate con tus colegas y no lo vuelvas a hacer:)
Muchos desarrolladores creen - y te dirán - que esto es demasiado estricto. Y es cierto que puedes salir bien sin ser tan estricto. Pero tomar este enfoque le ayudará a pasar de solo sobrevivir a un software notablemente robusto. Gastarás mucho menos. hora de arreglar errores.
Y con respecto a cualquier preocupación sobre el rendimiento, no lo hagas. Te garantizo que nunca, en toda tu carrera, escribirás código tan rápido que el cuello de botella sea la pila de llamadas en sí.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-05 23:48:44
OK, tiempo de votación descendente.
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, ya que 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 de prestigio". Si MSDN dice él, o algún famoso desarrollador o autor a quien todo el mundo le gusta lo dice, debe ser así.
Se basan en la idea de que las estructuras de datos tienen muchos estados inconsistentes, y deben protegerse contra la deambulación o la colocación en esos estados. Dado que (me parece) 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 datos de modo que tiende a ser normalizados y no tener estados inconsistentes. Entonces, si un miembro de una clase es cambiado, simplemente es cambiado, en lugar de dañado. Después de todo, de alguna manera un montón de buen software fue/está escrito en C, y que no sufren masivamente por falta de protecciones.
Se basan en la codificación defensiva llevada a los extremos. Se basa en la idea de que las clases serán utilizados en un mundo donde nadie código puede ser de confianza no ganso de sus cosas. Estoy seguro de que hay situaciones donde esto es cierto, pero Nunca los he visto. Lo que he visto son situaciones en las que las cosas se complicaron terriblemente para evitar protecciones para las que no había necesidad, y para tratar de proteger la consistencia de las estructuras de datos que eran terriblemente complicadas y no normalizadas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-05 23:55:42
Con respecto a los campos vs.propiedades, puedo pensar en 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 solo su clase puede verlo).
-
Exponer propiedades le da una manera 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 funcionan con las clases que usan reflexión solo se enfocan en propiedades (por ejemplo, creo que algunas bibliotecas para serialización funcionan de esta manera). El uso constante de propiedades facilita el uso de estas herramientas. NET estándar.
Con respecto a los gastos generales:
Si el getter / setter es la pieza de código habitual de una línea que simplemente lee/establece el valor de un campo, entonces el JIT debería ser capaz de alinear la llamada, por lo que no hay overhad de rendimiento.
-
Sobrecarga sintáctica se reduce en gran medida cuando se utilizan propiedades implementadas automáticamente (C# 3.0 y posteriores), por lo que no creo que esto sea un problema:
protected int SomeProperty { get; set; }De hecho, esto le permite hacer por ejemplo
setprotegido ygetpúblico muy fácilmente, por lo que esto puede ser aún más elegante que el uso de campos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-05 23:27:10
Los campos públicos y/o protegidos son malos porque pueden ser manipulados 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 se pierde la encapsulación, se pierde el contrato de la clase declarante; no se puede garantizar que la clase se comporta como se pretende o se espera.
El uso de una propiedad o un método para acceder al campo le permite mantener la encapsulación y contrato de la clase declarante.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-05 23:27:33
En realidad depende de si su clase es una clase data o una clase behaviour.
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 behaviour, entonces no debería exponer ningún dato.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-06 10:27:07
Estoy de acuerdo con la propiedad de solo lectura answer. Pero 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 comento, sigo pautas ni ninguna de las formalidades).
Pero cuando estoy en el trabajo esa es una historia diferente.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-07-05 23:51:01