¿Cómo asegurar la evolución de un sistema?" - Parte II - Visitor

Que tal,
algo que estuve haciendo últimamente tiene que ver con cómo asegurar en un ambiente dinámicamente tipado la implementación correcta del patrón Visitor.
Los problemas que este patrón puede generar son:
1) La clase root de la jerarquía de clases que se visita no implementa el mensaje #accept: como subclassResponsibility
2) Los visitors no implementan todos los mensajes que envían lo objetos que se pueden visitar
3) Lo contrario de la 2), los visitors implementan mensajes que no se envían desde los objetos que se visitan

Aquellos programadores defensores del tipado estático arremeterían contra los lenguajes dinámicos argumentando que estos errores no sucederían en dichas herramientas. La verdad es que a simple vista pareciera que no sucederían, sin embargo no es tan así.
En el caso del punto 1) , este error se vería evidenciado solo al momento de utilizar un Visitor sobre dicha jerarquía y únicamente si la variable del objeto que se quiere visitar está "claseada" (tipada) con la clase root que acepta visitors. Este error puede por lo tanto, pasar inadvertido por bastante tiempo (a menos que se esté utilizando TDD)
El punto 2) es donde se hace efectivo el chequeo de tipos puesto que no sería factible que un objeto visitado pueda enviar un mensaje no definido en el visitor que recibe como colaborador. Sin embargo el punto 3), que es el caso que típicamente se da en la evolución de un sistema, no es evidenciado como error por un sistema de tipos. Este caso se da al borrar por ejemplo, una clase de la jerarquía que es visitada.
Como podemos ver, hay ciertos aspectos del patrón Visitor que un sistema de tipos no puede asegurar. Es por ello que muchas veces se ha hablado de reificar los patrones como "first class objects", hacerlos de alguna manera, parte del metamodelo.
Sin embargo, cómo puse más arriba, hay 3 condiciones que se deben cumplir para que un visitor esté correctamente implementado, es por ello que implementé 3 test utilizando SUnit que verifican dichas condiciones: (Estos test los llamamos test de "Estándares de Código" y solamente se corren antes de cerrar una "unidad de trabajo")
1) Toda clase que defina el mensaje #accept: debe tener una superclase que implemente el #accept: como subclassResponsibility o indicar cual es la clase root de la jerarquía que acepta el visitor (esta última parte se debe a aquellas clases que quedan mal clasificadas por diversos motivos, pero que aún así deben poder ser visitadas por el mismo visitor que las clases que se encuentran bien clasificadas). Es importante que este test no falle puesto que de hacerlo puede haber algún objeto instancia de una clase de la jerarquía visitada que no implemente el mensaje #accept:. Este test hace uso de otro test que verifica que todo mensaje definido como subclassResponsibility es implementado en las subclasses concretas.
2) Todo objeto que sepa responder a un mensaje #visitXXXX:, debe saber responder a todos los mensajes #visitXXX: que son enviados por los objetos que pertenecen a la jerarquía que define la clase root que acepta el visitor
3) Los mensajes #visitXXX: que sabe responder un objeto deben ser igual al protocolo que define el Visitor. Si hay algún otro mensaje #visitXXX: implementado por un objeto que no corresponde a los visitors que dicho objeto implementa, quiere decir que el método que implementa ese mensaje es candidato a ser eliminado.
Para implementar estos test reifique algunos conceptos como VisitorProtocol y VisitorImplementation, de tal manera que se puede crear el VisitorProtocol de esta manera:

visitorProtocol := VisitorProtocol for: aClassRootAcceptingVisitor

y luego colaborar con visitorProtocol de la siguiente manera:

visitorProtocol isValid <-- Indica si el protocolo es válido, i.e., no tiene mensajes #visitXXX: repetidos
visitorProtocol implementors <-- Devuelve todas las clases que implementan el protocolo

y con un VisitorImplementor se puede:

visitorImplementor isValid <-- Indica si este implementor implementa correctamente el visitor
visitorImplementor missingImplementors <-- Devuelve los mensajes que no están implementados por este visitor
visitorImplementor implementMissingImplementors <-- Crea un implementación default para todos aquellos mensajes que no están implementados
visitorImplementor extraImplementors <-- Devuelve los mensajes que sobran en la implementación
visitorImplementor deleteExtraImplementors <-- Borra los mensajes que sobran en la implementación

Lo interesante de esta implementación es que mientras se está desarrollando y experimentando con un modelo, se pueden romper estas reglas, de hecho se hace constantemente y solo son verificadas en el momento oportuno. Y como toda regla, puede tener sus excepciones, algo imposible de hacer con un sistema de tipos cerrado.
Conclusiones:
1) Reificar las reglas de desarrollo que define el grupo de trabajo en el que se encuentran
2) Implementar test que verifiquen dichas reglas
3) Hacer estos test de tal manera que solo corran en el momento oportuno, que no sean una molestia

En definitiva, hacer que los mismos objetos se responsabilicen de su evolución (en este caso a través de 1, 2 y 3).