c# - sirve - ¿Deberías usar las propiedades de acceso dentro de la clase, o solo desde fuera de la clase?
propiedades de una clase c# (9)
Aparte del punto hecho por otros, si se debe usar un acceso directo o un campo directamente, puede ser necesario que se informe por semántica. Algunas veces, la semántica de un consumidor externo que accede a una propiedad es diferente de la necesidad mecánica de acceder a su valor mediante un código interno.
Eric Lippert recientemente blogueó sobre este tema en un par de publicaciones:
propiedades automáticas vs explícitas
diseño a prueba de futuro
Esta pregunta ya tiene una respuesta aquí:
Tengo una clase ''Datos'' que usa un getter para acceder a una matriz. Si la matriz es nula, entonces quiero que Data acceda al archivo, llene la matriz y luego devuelva el valor específico.
Ahora aquí está mi pregunta:
Cuando cree getters y setters, ¿debería usar esas mismas propiedades de acceso como su forma de acceder a esa matriz (en este caso)? ¿O debería simplemente acceder a la matriz directamente?
El problema que estoy teniendo al usar los accesores dentro de la clase es que obtengo bucles infinitos a medida que la clase llamante busca información en Data.Array, el getter encuentra la matriz nula para obtenerla del archivo y esa función finaliza volviendo a llamar al getter desde Data, array vuelve a ser nulo y estamos atrapados en un bucle infinito.
EDITAR:
Entonces, ¿no hay una postura oficial sobre esto? Veo la sabiduría de no usar Accessors con acceso a archivos en ellos, pero algunos de ustedes dicen que siempre usan accesodores desde dentro de una clase, y otros dicen que nunca usen accessors desde la clase ......... ...................................
Creo que es una buena idea usar siempre los accesorios. Entonces, si necesita alguna lógica especial al obtener o configurar la propiedad, sabe que todo está llevando a cabo esa lógica.
¿Puedes publicar el getter y el setter para una de estas propiedades? Quizás podamos ayudar a depurarlo.
Escribí un getter que abre un archivo y siempre lo lamenté más tarde. Hoy en día, nunca resolvería ese problema haciendo construcciones perezosas a través del período getter. Está el problema de los captadores con efectos secundarios en los que las personas no esperan todo tipo de actividades locas detrás del captador. Además, es probable que tengas que garantizar la seguridad del hilo, lo que puede contaminar aún más este código. Las pruebas unitarias también pueden volverse un poco más difíciles cada vez que haces esto.
La construcción explícita es una solución mucho mejor que todo tipo de captadores de iniciación floja. Puede ser porque estoy usando marcos DI que me dan todo esto como parte de los patrones de uso estándar. Realmente trato de tratar la lógica de construcción de la manera más clara posible y no esconderme demasiado, hace que el código sea más fácil de entender.
Estoy de acuerdo con Krosenvold, y quiero generalizar un poco su consejo:
No utilice los captadores de propiedades y los configuradores para operaciones costosas, como leer un archivo o acceder a la red. Use llamadas a funciones explícitas para las costosas operaciones.
En general, los usuarios de la clase no esperarán que una simple recuperación o asignación de propiedad tome mucho tiempo.
Esto también se recomienda en las Pautas de diseño de marco de Microsoft. ;
Use un método, en lugar de una propiedad, en las siguientes situaciones .
La operación es de órdenes de magnitud más lenta de lo que sería un conjunto de campos. Si incluso está considerando proporcionar una versión asíncrona de una operación para evitar el bloqueo del hilo, es muy probable que la operación sea demasiado costosa como para ser una propiedad. En particular, las operaciones que acceden a la red o al sistema de archivos (que no sea una vez para la inicialización) deberían ser métodos, no propiedades.
Si lo estoy entendiendo bien, está intentando acceder a una propiedad desde su implementación (utilizando un método que llama a la misma propiedad en el código de implementación de la propiedad). No estoy seguro de si existen normas oficiales con respecto a esto, pero lo consideraría una mala práctica, a menos que haya una necesidad específica de hacerlo.
Siempre prefiero usar miembros privados dentro de una clase en lugar de propiedades, a menos que necesite la funcionalidad que proporciona la implementación de la propiedad.
Si usar un método Get conduce a este tipo de error, debe acceder al valor directamente. De lo contrario, es una buena práctica usar sus accesorios. Si debe modificar el getter o el setter para realizar acciones específicas en el futuro, romperá su objeto si no puede usar esa ruta.
Siempre debe usar los descriptores de acceso, pero la función que lee el valor del archivo (que debe ser privada, y se llama algo así como getValueFromFile ) solo se debe invocar cuando el valor debe leerse del archivo, y debe simplemente leer el archivo y devolver los valores. Esa función incluso podría estar mejor en otra clase, dedicada a leer valores de su archivo de datos.
Supongo que lo que intentas implementar es una especie de propiedad de carga lenta, donde cargas los datos solo cuando se accede por primera vez.
En tal caso, utilizaría el siguiente enfoque para evitar el ciclo infinito:
private MyData _data = null;
public MyData Data
{
get
{
if (_data == null)
_data = LoadDataFromFile();
return _data;
}
}
private MyData LoadDataFromFile()
{
// ...
}
En otras palabras:
- no implementar un setter
- use siempre la propiedad para acceder a los datos (nunca use el campo directamente)
No. No creo que debas, la razón: código mantenible.
He visto personas usar propiedades dentro de la clase definitoria y al principio todo se ve bien. Luego aparece otra persona y agrega características a las propiedades, luego aparece otra persona e intenta cambiar la clase, no comprende completamente la clase y todo el infierno se desata.
No debería ser así porque los equipos de mantenimiento deben comprender completamente lo que están tratando de cambiar, pero a menudo están viendo un problema o error diferente y la propiedad encapsulada a menudo se les escapa. Lo he visto mucho y nunca uso las propiedades internamente.
También pueden ser un cerdo de rendimiento, lo que debería ser una búsqueda simple puede volverse desagradable si alguien pone el código de la base de datos en las propiedades, ¡y también he visto a gente hacer eso!
¡El principio de KISS sigue siendo válido después de todos estos años ...!