php - orientado - Diseño de POO: ¿Dónde/cuándo validar las propiedades?
php es un lenguaje de programación orientado a objetos (7)
He leído algunos libros sobre OOP DDD / PoEAA / Gang of Four y ninguno de ellos parece abarcar el tema de la validación; parece que siempre se supone que los datos son válidos.
De las respuestas a esta publicación ( OOP Design Question - Validating properties ), recojo que un cliente solo debe intentar establecer un valor de propiedad válido en un objeto de dominio.
Esta persona ha formulado una pregunta similar que permanece sin respuesta: http://bytes.com/topic/php/answers/789086-php-oop-setters-getters-data-validation#post3136182
Entonces, ¿cómo se asegura de que sea válido? ¿Tiene un ''método de validación'' junto a cada captador y configurador?
- isValidName ()
- escoger un nombre()
- getName ()
Parece que me faltan algunos conocimientos básicos básicos sobre la validación de datos OOP. ¿Puede indicarme un libro que cubra este tema en detalle? - es decir cubriendo diferentes tipos de validación / invariantes / manejo de retroalimentación / para usar Excepciones o no, etc.
Cada objeto debe asegurarse de que su estado interno sea coherente, por lo que la validación se realiza mejor antes de que se modifique el estado interno, en los métodos de establecimiento del objeto.
En definitiva, siempre validar. En mucho tiempo, realice sus validaciones todas juntas a la vez, no ''en el camino''. Esto ayudará a que su código permanezca optimizado y ayudará a depurar la confusión.
En mi experiencia, la validación se produce cuando hay aportaciones de usuarios / humanos. Y esto suele suceder cuando permites que tu método cambie algo. En su ejemplo, me gustaría validar el método:
setName()
Así sucede cuando se permite la entrada de valores / valores de configuración que resultan ser métodos de establecimiento.
Es importante distinguir entre válidos en el sentido de invariantes de un objeto de dominio (que siempre deben cumplirse) y lo que algunas personas llaman " validación contextual". Por ejemplo, ¿un cliente con una cuenta bancaria negativa no es válido? No, pero es posible que no estén autorizados para realizar ciertos tipos de transacciones. Esa es la validación contextual , en contraste con "cada entidad cliente debe tener una ID que no sea nula", que es un tipo de validación completamente diferente.
Una técnica efectiva para imponer invariantes es distinguir las clases que representan la entrada del usuario de los objetos del dominio y no exponer mutadores no restringidos (por ejemplo, los accesores de conjuntos simples) en los objetos de su dominio.
Por ejemplo, si tiene un objeto de dominio de Student , no lo manipule directamente en la interfaz de usuario. En lugar de crear instancias de Student , sus vistas crean instancias de StudentBuilder que modelan lo que necesita para construir un objeto de dominio de Student válido.
A continuación, tiene clases que validan las instancias del constructor conforme a las invariantes del objeto del dominio, y fábricas que aceptan los constructores y pueden transformarlos en objetos de dominio válidos. (También puede introducir estrategias de validación contextual en este paso, según corresponda).
Esto depende de su estilo de programación, ya que Wikipedia tiene explicaciones más detalladas, simplemente rasparé la superficie y lo vincularé a Wikipedia. (Sí, soy ESO perezoso. :-))
NOTA: Todo esto NO se aplica a la entrada del usuario. Tienes que validarlo de cualquier manera. Solo estoy hablando de las clases de lógica de negocios que no deberían ser combinadas con la entrada del usuario de ninguna manera. :-)
- Defensivo
Como lo mencionaron otros, aplicará cada propiedad a sus límites. A menudo lanzaba excepciones de tiempo de ejecución (Java) para indicar esas fallas.
Wikipedia en programación defensiva
- Por contrato
Usted documenta los requisitos de su código y asume, por ejemplo, que los valores pasados a sus configuradores son válidos con respecto al contrato definido. Esto le ahorra un montón de código repetitivo. Pero la búsqueda de errores será un poco más difícil cuando se otorgue un valor ilegal.
Si controla el código que utiliza su clase, debe validar antes de intentar manipular las variables del objeto (a través de las propiedades públicas). Si está anticipando un escenario en el que no sabe cómo se usará su clase, entonces sí, debe validar dentro de la propiedad, eso es más o menos para lo que son. Obviamente, esto supone que la definición de "es un nombre válido" es una regla de negocio estática inherente al objeto.
Validar en ambos niveles es, por supuesto, la ruta más segura a seguir.
Una parte importante de la POO es también mantener su objeto en un estado válido. Por lo tanto, la validación se debe realizar después de una entrada que pueda modificar el objeto.
Siempre es bueno validar los datos procedentes de propiedades / conjunto, parámetros a funciones y constructor.