¿Verificaciones de datos en Getter/Setter o en otro lugar?

Question

Me pregunto si es una buena idea hacer verificaciones en captadores y colocadores, o en otra parte del código.

Esto podría sorprenderte cuando se trata de optimizaciones y exceso de velocidad subir el código, creo que no deberías hacer verificaciones en getters y setters, sino en el código donde estás actualizando sus archivos o base de datos.¿Me equivoco?

Answer 1

Bueno, una de las razones por las que las clases suelen contener miembros privados con captadores/definidores públicos es exactamente porque pueden verificar datos.

Si tiene un número que puede estar entre 1 y 100, definitivamente pondría algo en el configurador que lo valide y luego tal vez lanzaría una excepción que el código detecta.La razón es sencilla:Si no lo hace en el configurador, debe recordar esa limitación de 1 a 100 cada vez que lo configura, lo que genera código duplicado o, cuando lo olvida, genera un estado no válido.

En cuanto al rendimiento, estoy con Knuth aquí:

"Deberíamos olvidarnos de las pequeñas eficiencias, digamos aproximadamente el 97% de las veces:La optimización prematura es la fuente de todos los males."

Answer 2

@Terrapin, re:

Si todo lo que tiene es un montón de propiedades de [Simple Set Set/Get] ...Bien podrían ser campos

Las propiedades tienen otras ventajas sobre los campos.Son un contrato más explícito, están serializados, se pueden depurar más tarde, son un buen lugar para la extensión mediante herencia.La sintaxis más torpe es una complejidad accidental; .net 3.5, por ejemplo, supera esto.

Una práctica común (y defectuosa) es comenzar con campos públicos y convertirlos en propiedades más adelante, "según sea necesario".Esto rompe tu contrato con cualquiera que consuma tu clase, por lo que es mejor comenzar con las propiedades.

Answer 3

Eso depende.

Generalmente, el código debería fallar rápidamente.Si el valor se puede establecer mediante varios puntos del código y lo valida solo después de recuperar el valor, el error parece estar en el código que realiza la actualización.Si los configuradores validan la entrada, sabrá qué código está intentando establecer valores no válidos.

Answer 4

Desde la perspectiva de tener el código más fácil de mantener, creo que deberías hacer tanta validación como puedas al establecer una propiedad.De esta manera no almacenará en caché ni tratará con datos no válidos.

Después de todo, para eso están destinadas las propiedades.Si todo lo que tienes es un montón de propiedades como...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

...también podrían ser campos

Answer 5

Quizás quieras echarle un vistazo Diseño impulsado por dominio, por Eric Evans.DDD tiene esta noción de Especificación:

...Objetos de valor de tipo predicado explícito para fines especializados.Una especificación es un predicado que determina si un objeto realiza o no algunos criterios.

Creo que fallar rápidamente es una cosa y la otra es dónde guardar la lógica para la validación.El dominio es el lugar adecuado para mantener la lógica y creo que un objeto de especificación o un método de validación en los objetos de su dominio sería un buen lugar.

Answer 6

La validación debe capturarse por separado de los captadores o definidores en un método de validación.De esa manera, si es necesario reutilizar la validación en varios componentes, estará disponible.

Cuando se llama al configurador, se debe utilizar dicho servicio de validación para desinfectar la entrada al objeto.De esa manera sabrás que toda la información almacenada en un objeto es válida en todo momento.

No necesita ningún tipo de validación para el captador, porque ya se confía en que la información sobre el objeto sea válida.

¡¡No guardes tu validación hasta que se actualice la base de datos!!Es mejor Fallar rapido.

Answer 7

me gusta implementar IDataErrorInfo y puse mi lógica de validación en sus propiedades Error y this[columnName].De esa manera, si desea verificar mediante programación si hay un error, simplemente puede probar cualquiera de esas propiedades en el código o puede transferir la validación al enlace de datos en Web Forms, Windows Forms o WPF.

La propiedad de enlace "ValidatesOnDataError" de WPF hace que esto sea particularmente fácil.

Answer 8

Intento nunca permitir que mis objetos entren en un estado no válido, por lo que los configuradores definitivamente tendrían validación, así como cualquier método que cambie de estado.De esta manera, nunca tendré que preocuparme de que el objeto con el que estoy tratando no sea válido.Si mantiene sus métodos como límites de validación, entonces nunca tendrá que preocuparse por los marcos de validación y las llamadas al método IsValid() esparcidas por todas partes.