Tipos de objetos
Para fines de nuestra discusión, separemos nuestros objetos en tres tipos diferentes:
Estos son los objetos que hacen el trabajo. Mueven dinero de una cuenta corriente a otra, cumplen con los pedidos y todas las demás acciones que esperamos que tome el software comercial.
Los objetos lógicos de dominio normalmente no requieren accesores (captadores y establecedores). Más bien, crea el objeto entregándole dependencias a través de un constructor, y luego manipula el objeto a través de métodos (decir, no preguntar).
Los objetos de transferencia de datos son de estado puro; No contienen ninguna lógica de negocios. Siempre tendrán accesores. Pueden o no tener setters, dependiendo de si los estás escribiendo o no de manera inmutable . Establecerá sus campos en el constructor y sus valores no cambiarán durante la vida útil del objeto, o sus accesos serán de lectura / escritura. En la práctica, estos objetos suelen ser mutables, de modo que un usuario puede editarlos.
Los objetos Ver modelo contienen una representación de datos visualizable / editable. Pueden contener lógica empresarial, generalmente limitada a la validación de datos. Un ejemplo de un objeto Modelo de vista podría ser un Modelo de factura de factura, que contiene un objeto Cliente, un objeto Encabezado de factura y Líneas de pedido de factura. Los objetos Ver modelo siempre contienen accesores.
Entonces, el único tipo de objeto que será "puro" en el sentido de que no contiene accesores de campo será el objeto Logic de dominio. Serializar un objeto de este tipo guarda su "estado computacional" actual, de modo que pueda recuperarse más tarde para completar el procesamiento. Los modelos de visualización y los DTO se pueden serializar libremente, pero en la práctica sus datos normalmente se guardan en una base de datos.
Serialización, dependencias y acoplamiento.
Si bien es cierto que la serialización crea dependencias, en el sentido de que debe deserializarse a un objeto compatible, no necesariamente se deduce que deba cambiar su configuración de serialización. Los buenos mecanismos de serialización son de uso general; no les importa si cambia el nombre de una propiedad o miembro, siempre que pueda asignar valores a miembros. En la práctica, esto solo significa que debe volver a serializar la instancia del objeto para que la representación de serialización (xml, json, lo que sea) sea compatible con su nuevo objeto; No deberían ser necesarios cambios en la configuración del serializador.
Es cierto que los objetos no deberían preocuparse por cómo se serializan. Ya ha descrito una forma en que tales preocupaciones se pueden desacoplar de las clases de dominio: reflexión. Pero el serializador debería preocuparse por cómo serializa y deserializa objetos; esa, después de todo, es su función. La forma en que mantiene sus objetos desacoplados de su proceso de serialización es hacer que la serialización sea una función de propósito general , capaz de funcionar en todos los tipos de objetos.
Una de las cosas sobre las que la gente se confunde es que el desacoplamiento tiene que ocurrir en ambas direcciones. No es asi; solo tiene que trabajar en una dirección. En la práctica, nunca puedes desacoplar por completo; siempre hay algo de acoplamiento. El objetivo del acoplamiento flexible es facilitar el mantenimiento del código, no eliminar todas las dependencias.