Patrones de diseo

Entre hoy y ayer en el trabajo he estado utilizando el patrn de diseo Visitor. Es mi primer encuentro directo con un patrn de la banda de los cuatro (GoF o Gang of Four), y mira que estuve pensando la solucin un buen rato hasta que mi jefe me cont lo del patrn en cuestin, que explicar brevemente a continuacin. El patron Visitor se utiliza cuando existe una clase padre A y una o varias clases hijas A1, A2, , AN; todas tienen un metodo comun, por ejemplo metodo1() que realiza diferentes tareas dependiendo del tipo de la clase. Para qu puede servir esto? Pues para iterar por una lista de clases A e hijas y llamar al metodo1 en cada clase. El problema surge en que para recorrer la lista, el tipo del objeto (item) en cada iteracion debe ser de tipo A (el padre), y que si se llama a item.metodo1() se ejecutara el metodo1 contenido en la clase padre! En lugar de lo correcto, que sera ejecutar el metodo1 de la clase hija a la que pertenezca el item. La solucion consiste en crear un metodo accept(VisitanteA visitante) en todas las clases A e hijas que acepte un visitante (una clase de tipo VisitanteA). En el metodo accept se llama al mtodo visit de la clase visitante que se paso como parametro, y el unico parametro del mtodo visit es this, un puntero al objeto actual. En la clase VisitanteA se implementa un mtodo visit(A param), otro visit(A1 param), otro visit(A2, param), etc. Uno por cada clase que se quiera visitar. En ese mtodo visit(Ax param) es dnde se ejecuta la lgica de nuestro antiguo mtodo1(). De este modo, el Visitante descubre la clase del objeto, ya que el objeto se enva a si mismo y debido a la sobrecarga del mtodo visit() se ejecutan las sentencias correctas. Espero haberlo explicado medianamente bien. Por el momento he implementado como 4 o 5 clases visitantes. Tengo muchas herencias inusuales y restricciones semnticas en la base de datos que requieren del patrn. Todo esto me pasa por mover el modelo a la base de datos, en lugar de implementarlo en la lgica de negocio. Sin embargo, considero que este enfoque es mejor y ms mantenible, aunque ms laborioso. En fin, veremos como acaba el proyecto.

El problema surge en que para recorrer la lista, el tipo del objeto (item) en cada iteracion debe ser de tipo A (el padre), y que si se llama a item.metodo1() se ejecutara el metodo1 contenido en la clase padre! En lugar de lo correcto, que sera ejecutar el metodo1 de la clase hija a la que pertenezca el item. ES TOTALMENTE ERRONEO! El mtodo a ejecuta se determina en tiempo de ejecucin segn el tipo dinmico del objeto No se ejecuta el mtodo del tipo base. Esto es una de las bases de la POO, as que me pareca importante comentartelo.