Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer

En su excelente libro Domain Driven Development, Eric Evans hace una clasificación de los diferentes tipos de objetos de dominio que es probable que te encuentres:
1. Entidad (Entity): Los objetos que tienen una identidad distinta que traspasa el tiempo y representaciones diferentes. También los habrás oído llamar " objetos referencia".
2. Objeto Valor (Value object): Lo importante de estos objetos es únicamente la combinación de sus atributos. Dos objetos valor con los mismos valores para todos sus atributos son considerados iguales. También describo objetos valor en P de EAA.
3. Servicio (Service): Una operación independiente (standalone) dentro del contexto de su dominio. Un Objeto Servicio recoge uno o varios servicios en un objeto. Típicamente se tendrá sólo una instancia de cada tipo de objeto servicio dentro de tu contexto de ejecución.

Esta clasificación encaja bien con mi experiencia, de lo que se necesita en modelos de dominio. El problema es que el trío es difícil de definir con precisión, son de los de la categoría " los reconozco cuando los veo".

Escrito por Martin Fowler
Traducido por Ismael Ferrer
Revisado por Carmen Vidal

Gerard Meszaros está trabajando en un libro que recopile patrones de uso de los diferentes frameworks de pruebas Xunit. Una de las cosas más incómodas con las que se ha topado ha sido la variedad de nombres para stubs, mocks, fakes, dummies y otras cosas por el estilo que se usan para sustituir parte del sistema en las pruebas. Para solucionar esto ha creado su propio vocabulario que creo merece la pena difundir.

El término genérico que usa es Doble para Pruebas (Test Double) – a semejanza del doble de un actor-. Doble para Pruebas es un término genérico a usar en cualquier caso en que sustituyes un objeto real por otro para pasar las pruebas. Gerard enumera varios tipos de dobles:

• Dummy: Objeto que se pasa pero que en realidad nunca llega a ser usado. Normalmente sólo se usan para rellenar listas de parámetros.
• Fake: Objeto que tiene una implementación operativa, pero que usualmente toman algún atajo que hace que sea inapropiada para producción (una BaseDeDatosEnMemoria es un buen ejemplo).
• Stub: proporciona respuestas enlatadas a las llamadas hechas durante el test, normalmente no responde en absoluto a nada que esté fuera de lo programado en el test.

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Carmen Vidal

Actualizado con un ejemplo, puesto que el artículo original era demasiado seco.

Ha habido desde siempre una discusión entre los defensores del Diseño por Contrato (DbC) y del Desarrollo Dirigido por pruebas (TDD). No voy a ahondar en ello ahora, pero sugiero la idea de combinar ambos, idea que surgió mientras hablaba con Daniel Jackson.

En el DbC se define una invariante para cada clase. Esta invariante establece las propiedades de la clase que siempre se deberán cumplir. Un objeto debe siempre satisfacer su invariante (a menos que esté en el medio de algo). Con Eiffel la invariante de la clase se comprueba siempre de forma automática antes (al comprobar al pre-condición) y después (al comprobar la post-condición) de la llamada de un método. Un fallo en la invariante lanza una excepción. (Esta comprobación puede ser desactivada en producción a efectos de rendimiento)

Aplicar esta idea al TDD significa que hay que definir un método común para probar la invariante en las clases de producción, así como probarlo en el código de test.

Es el momento del ejemplo trivial de costumbre.

public class Bowler ... [jugador de cricket]
int overs, runs, wickets;

Escrito por Martin Fowler
Traducido por Miguel Figueroa
Revisado por Carmen Vidal

El término ' separación comando-pregunta' fue acuñado por Bertrand Meyer en su libro “Construcción de Software Orientado a Objetos” – uno de los libros de OO mas influyentes en los primeros días de la OO. (la primera edición es la que tuvo influencia, la segunda edición es buena pero se necesitarán varios meses en un gimnasio antes de poder levantarlo.)

La idea fundamental es que debemos dividir los métodos de un objeto en dos categorías bien definidas:
• Preguntas: Devuelve un resultado y no cambia el estado observable del sistema (libre de efectos secundarios).
• Comandos: Cambia el estado de un sistema pero no devuelve un valor.

Debido a que el término “comando” se utiliza extensamente en otros contextos prefiero llamarlos “modificadores”, también se puede ver el término “mutantes”.

La idea realmente valiosa en este principio es que es ayuda mucho si uno/se puede separar claramente los métodos que cambian el estado de los que no lo hacen. Esto es porque uno puede utilizar preguntas en muchas situaciones con mucha más confianza, introduciéndolas en cualquier sitio, cambiando su orden. Uno debe ser más cuidadoso con los modificadores.

Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer

¿Qué quiere decir la gente cuando dicen que un método no cambia el estado observable de un objeto?

Es muy útil diferenciar entre aquellos métodos que cambian el estado y aquellos que no lo hacen. Los métodos que no cambian el estado (lo que llamo consultas), pueden ser usados en cualquier contexto sin preocuparnos del orden en que se ejecutan cuando se mezclan con otros métodos.