Si dos objetos A y B hacen referencia a un tercero C y A cambia el estado de C entonces B no debería confiar en el estado de C.
Una posible solución es no compartir los objetos en los que se confía si no hacer copias de los mismos. Esto lleva a un mayor uso de espacio y tiempo. Otra solución sería utilizar el patrón Observer de manera que se avise explícitamente de la modificación cuando se produzca un cambio. Esto complica los flujos de control y la lógica.
Otra solución es tratar al objeto como un objeto que no cambia. De esta manera se podrá hacer referencia a él sin miedo a que cambie el estado.
Cuando se implementa el patrón «Value Object» cada operación que se define sobre un objeto devuelve un nuevo objeto sin alterar el objeto original desde el que se hizo la operación.
Cuando se usa un patrón «Value Object» todos los objetos que lo implementan deberían implementar un mecanismo para comprobar la igualdad entre dos de ellos. Cinco euros deberían ser iguales a cinco euros independientemente de si son referencias al mismo objetos o si son objetos distintos con el mismo valor.
El software nos rodea. Está por todas partes, incluso ahora mismo, en esta habitación, puedes verla si miras por la ventana o al encender la televisión. Puedes sentirlo, cuando vas a trabajar, cuando vas al supermercado, cuando pagas tus impuestos. Es el mundo tecnológico que se ha puesto ante tus ojos para ocultarte la verdad: que eres un esclavo del software. Sobre todo del mal software.
lunes, 2 de julio de 2018
Capítulo 33: Design Pattern - Value Object - TDD By Example
Etiquetas:
Kent Beck,
tdd,
TDD By Example,
Test-Driven Development
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario