El Homologous Factory

Si bien los homólogos encapsulan la biblioteca gráfica elegida, sería bastante tedioso el proceso de crearlos uno a uno, setear sus atributos y asociarlos con sus actores correspondientes. Más complejo aún sería migrar la aplicación a otra biblioteca gráfica cambiando todas las instancias de los homólogos. Un mecanismo de alto nivel para crearlos en forma transparente y asociarlos con los actores sería lo ideal. Más aún, es deseable poder cambiar de biblioteca en forma transparente en cualquier momento. Afortunadamente un mecanismo de tales características existe y es un conocido pattern; el Abstract Factory. El lector con experiencia en BiCoTI-I, debería conocer otro pattern de esta familia; el Factory Method usado para construir los iteradores de cada implementación.
En aquel caso la interface de las implementaciones declaraba un método CreateIterator() que se implementaba en cada clase particular para retornar el iterador adecuado. Este mecanismo es posible gracias a la existencia de un único tipo de iterador asociado a cada implementación.
Marcando diferencias con el caso anterior destacamos la existencia de una gran variedad de tipos homólogos a asociar a un actor, lo que hace imposible usar el mismo esquema. El mecanismo en este caso, consiste en especializar una interface abstracta (el bicotiHomologousFactory), implementando el método CreateHomologous() que recibe un actor, usa los métodos introspectivos de este para identificarlo, crear y setear el homólogo adecuado.

Figure 21: El bicotiHomologousFactory

Con este sencillo mecanismo, se consigue por ejemplo cambiar de QT a WX Windows cambiando un solo objeto; el Factory.