Hay un comentario de Gabriel (gaboto) en el post de la conferencia de la ECI donde me pide aclarar un comentario que hice en la presentación relacionado a los IFs. El comentario tenía que ver con el hecho de que los IFs no tienen información "meta". Lo voy a tratar de explicar con el ejemplo de la presentación.
En dicho ejemplo, una de los cambios de diseño que mostré fue reemplazar una serie de IFs por objetos que se encargan de "tipificar" un objeto. Al haberlo hecho hay mucha información que se está poniendo en el código que antes no estaba. Ahora para tipificar un objeto no se utiliza una construcción tan genérica como el IF sino una más concreta que se encarga justamente de "tipificar" objetos. En pocas palabras, a partir de ese momento cuando un programador lee el código se dará cuenta que se está tipificando un objeto simplemente por ver qué objeto (clase en este caso) se está usando.
Algo similar sucede con los patrones; cuando se ve un "state" se entiende para qué está, su función, etc. Si en vez de un "state" hubiese un conjunto de IFs o CASEs, habría que leer lo que está escrito, interpretarlo, etc. para llegar a la conclusión de que se está programando un "state" (a menos que exista un comentario que diga eso, pero así y todo, no se puede deducir información automáticamente de un comentario, solo lo puede interpretar un ser humano).
Un IFs, lo único que indica es que se está tomando una decisión, pero no da indicios sobre qué decisión, por qué, etc., para obtener esa información alguien tiene que "interpretar" el IFs, y solo los seres humanos lo pueden hacer (al menos por ahora... :-) ) De la otra manera no solo le resulta directa la interpretación al ser humano sino que también se puede utilizar esa información de manera automática. Por ejemplo, si se quiere ver todas aquellas clases cuyas instancias son tipificadas, se busca las referencias a la clase que implementa esa responsabilidad y listo. Si se quisiese hacer estadísticas sobre la cantidad de tipos que existen, se puede a partir de estas referencias ver la jerarquía de tipos sobre las que trabajan y obtener todas las subclases de la clase raíz de cada jerarquía y obtendríamos dicha información, etc.
En pocos palabra, no es que el IFs no indique nada sobre lo que se está haciendo, sino que al ser tan genérico se pierde información, información que luego debe ser reconstruida por el programador cada vez que lo lee. De la otra manera, al utilizar un objeto más específico existe información que puede ser interpretada más fácilmente y de manera automática. A esto me refiero con información "meta". Estos objetos que reemplazan al IFs no solo hacen lo que tienen que hacer sino que ofrecen información "más allá de lo que hacen", información sobre el código en el cual están siendo utilizados, o sea, meta-información sobre el programa.
Bueno, espero haber logrado explicar mi idea. Cualquier duda chiflen!
Suscribirse a:
Comentarios de la entrada (Atom)
2 comentarios:
Si se entendió, gracias :).
Sería como crear un concepto mas en el ambiente, el concepto de "tipificacion", y también programarlo para reutilizarlo, con la posibilidad de ir enriqueciendolo con mas y mejores herramientas.
Se me viene a la cabeza la idea de tener patrones implementados de manera genérica, de manera de poder reutilizarlos.
No se si es el mejor ejemplo, pero se podría tener el patrón state en forma genérica, quiza como una metapropiedad, medio como un mecanismo del lenguaje, en donde a una clase cuyas instancias tienen que tener estados ya tenga incorporada todo ese comportamiento. De esta manera se podría indicar bajo que condiciones se suceden las transiciones. Además los objetos automaticamente tendrían el protocolo que permita realizar transiciones de estados, etc. Así se estaría agregando información meta también. Porque podrian extraerse estadisticas, hacer chequeos automaticos sobre los estados, etc.
Que haces Gaby,
lo que comentas lo hemos pensado varias veces y de hecho una tesis que estoy dirigiendo (el tesista está medio atrasado :-) ) está haciendo algo parecido.
El problema con esto es que al crear una construcción de este tipo hay que también proveer herramientas para que pueda ser usado fácilmente. En el caso que mostré alcanzaba con el browser, pero en el caso del state no es tan sencillo y no alcanzaría con el browser. Hay investigación hecha respecto de reificar los design patterns, pero pareciera ser que es mejor dejarlos como construcciones de diseño...
Publicar un comentario