Capítulo 33: Design Patterns - Imposter - TDD By Example

Para introducir nuevas variaciones en un proceso se puede introducir un nuevo objeto con el mismo protocolo que el objeto que existe pero con la nueva implementación.

Si la variación se puede aplicar en un lugar que sea obvio y además no se está duplicando el código entonces se puede aplicar la variación con una instrucción «if». En otras ocasiones la variación requerirá del cambio en varios métodos.

Se deberá escribir una prueba para la variación ya que se necesita representar el nuevo escenario. Por ejemplo si se está probando un editor gráfico y ya está probado que se dibujan correctamente los objetos de tipo rectángulo con una prueba como la siguiente.

Si queremos dibujar un óvalo, en este caso el Impostor debería reemplazar el objeto de clase «RectangleFigure» por «OvalFigure».

Generalmente, detectar la posibilidad de utilizar un «Imposter» requiere de un poco de conocimiento. La percepción de Ward expone que un vector de dinero puede actuar como dinero es precisamente ese momento.

Dos ejemplos de «Imposter» que vienen durante la refactorización:

• «Null Object»: se puede tratar la ausencia de datos al igual que la presencia de datos.
• «Composite»: se puede tratar una colección de objetos como si de un objeto se tratase.

Encontrar dónde aplicar «Imposter» durante la refactorización reduce la duplicación de código al igual que toda refactorización es para eliminar la duplicación.