OOP Design - Where/Where do Validate properties?

Question

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 asume que los datos son válidos.

que deduzco de las respuestas a este post (OOP Design Question - Validating properties) que un cliente sólo debe tratar de establecer un valor propiedad válida en un objeto de dominio.

Esta persona ha hecho una pregunta similar que sigue sin respuesta: http://bytes.com/topic/php/answers/789086-php-oop-setters-getters-data-validation#post3136182

Entonces, ¿cómo asegurarse de que es válida? ¿Tiene un 'método de validación' junto con cada getter y setter?

• isValidName()
• setName()
• getName()

Me parece que faltan algunos conocimientos básicos clave sobre la validación de datos orientada a objetos - puede que me señale un libro que cubre este tema en detalle? - es decir. que cubre diferentes tipos de validación/invariantes/manejo de comentarios/para usar excepciones o no, etc.

Answer 1

En mi experiencia, la validación se produce cuando hay datos humanos/de usuario. Y esto generalmente sucede cuando permites a través de tu método cambiar algo. En su ejemplo, me gustaría ir para la validación del método:

setName() 

así sucede cuando se permite la entrada de los valores/ajuste de valores que resulta ser métodos setter.

Answer 2

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 setter del objeto.

Answer 3

En resumen, validar siempre. En largo, realice sus validaciones todas juntas a la vez, no 'en el camino'. Esto ayudará a que su código se mantenga optimizado y ayudará a eliminar la confusión.

Answer 4

Si controla el código que usa su clase, entonces debe validar antes incluso 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 es. Obviamente, esto supone que la definición de "es un nombre válido" es una regla empresarial estática inherente al objeto.

La validación en ambos niveles es, por supuesto, la ruta más segura para llevar.

Answer 5

Una parte importante del OOP también es mantener siempre su objeto en un estado válido. Por lo tanto, la validación debe hacerse después de una entrada que podría modificar el objeto.

Siempre es bueno validar los datos que provienen de las propiedades/conjunto, los parámetros de las funciones y el constructor.

Answer 6

Es importante distinguir entre invariantes en el sentido de invariantes de un objeto de dominio (que siempre deben cumplirse) y lo que algunas personas llaman "contextual validation." Por ejemplo, ¿es inválido un cliente con una cuenta bancaria negativa?" No, pero es posible que no estén autorizados para realizar ciertos tipos de transacciones.Eso es validación contextual, a diferencia de "cada entidad de cliente debe tener una ID no nula", que es un tipo diferente de validación por completo.

Una técnica efectiva para imponer invariantes es distinguir las clases que representan la entrada del usuario de los objetos de dominio y no exponer mutadores no restringidos (simples accesadores de conjuntos, por ejemplo) en los objetos de su dominio.

Por ejemplo, si tiene un objeto Student de dominio, no manipularlo directamente en la interfaz de usuario. En lugar de crear Student casos, sus puntos de vista crean StudentBuilder casos que el modelo de lo que necesita para construir un objeto Student dominio válido.

A continuación, usted tiene que validan clases casos constructor ajustarse a los invariantes del objeto de dominio, y unas fábricas que se lleva a aceptar los constructores y pueden transformarse en objetos de dominio válido. (También puede introducir estrategias de validación contextual en este paso, según corresponda.)

Answer 7

Esto depende de su estilo de programación, ya que Wikipedia tiene explicaciones más detalladas, solo arañaré la superficie y enlazaré a Wikipedia. (Sí, soy así de 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 combinarse con la entrada del usuario de ninguna manera. :-)

• defensiva

como han mencionado otros, que harán cumplir todas las propiedades a sus límites. A menudo lancé excepciones de tiempo de ejecución (Java) para indicar esas fallas.

Wikipedia on Defensive Programming

• Por Contrato

a documentar los requisitos de su código y asumir, por ejemplo, los valores pasados ​​a sus emisores son válidas 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 da un valor ilegal.

Wikipedia on Design by Contract