Objetos, modelos, comportamientos

Hace bastante tiempo que me da vueltas esta frase de un artículo del blog de Hernán Wilkinson:

"A lo que quiero llegar y aún me cuesta probar formalmente es que para mi tener un 'buen' modelo implica tener un isomorfismo entre los objetos del modelo y los entes del dominio. Esto significa que por cada ente del dominio hay un único objeto que lo representa"

Dejo de lado la cuestión del isomorfismo con una realidad, porque es un tema groso que es mejor tratar especialmente, más desde la filosofía que desde la informática. No obstante, me parece que habría que sacar la cuestión de la realidad del medio; que lo que se diga valga tanto si el dominio es la realidad (o parte de ella) como si no lo es.

Una definición de modelo que me pasaron hace mucho está muy en sintonía con la de Hernán: "Un sistema conceptual (abstracto) logrado mediante una representación isomórfica u homomórfica de un sistema concreto; en tanto construcción intelectual destinada a organizar las experiencias es siempre parcial y provisorio, y en la práctica todo modelo es incompleto porque deja de lado algunas propiedades del sistema original, e imperfecto porque la técnica de modelización introduce propiedades debidas al soporte del modelo". François, Charles. Diccionario de Teoría General de Sistemas y Cibernética.

La aclaración de que el modelo puede ser isomórfico u homomórfico es muy importante, porque el isomorfismo es simétrico, lo que implicaría que para todo objeto del modelo, hay un único ente del dominio del cual es representación. Y esto llevaría por un lado al problema de si entes como los números, las colecciones y las clases abstractas de una jerarquía forman parte del dominio. Algunos dirían que los números son entidades que forman parte de cualquier dominio. Y que en la medida en que el dominio esté concebido en términos de jerarquía, entonces las clases abstractas están implícitas en esa jerarquía y que al modelarlas con objetos (si es que la implementación utiliza herencia) lo que se hace es explicitarlas.

Yo no afirmaría tan categoricamente que los números, los conjuntos y otras abstracciones forman parte de cualquier dominio. Tomo como ejemplo la escritura musical; se trata sin duda de un modelo de la música "real". Es una representación isomórfica, pues para (casi) todo ente del dominio, es decir, cada nota, cada instrumento, cada articulación, etc., hay un ente (un gráfico) en el modelo. Si tuviésemos que hacer un software que modele este modelo que es la escritura musical, deberíamos recurrir a la matemática como pocas veces; sin embargo, es posible leer música sin saber sumar. Hoy encontré una frase de Leibniz en la reseña del libro Matemática maestro que ilustra muy bien esto: "La música es un ejercicio de aritmética inconsciente, y el que se entrega a ella ignora que maneja números." Los números sólo son necesarios cuando por alguna razón hay que salir de ese estado de "ignorancia" con algún propósito, como entender ciertas leyes, ciertas regularidades. Un software que, por ejemplo, deba traducir la escritura musical a notas, deberá saber qué es la raiz doceava de dos; un músico no necesita de ese conocimiento para saber que dos manchas en dos posiciones distintas en un papel, significan que tiene que mover un dedo de un lugar a otro.

Si, siempre se puede insistir con las relaciones implícitas. Yo prefiero pensar que más que sacar algo que está ahí, lo que hacemos es poner algo que está en nosotros: interpretar.

En ese caso, tanto las grandes abstracciones, las clases abstractas, junto con las que surgen sólo por necesidades de implementación y toda la parafernalia de objetos que puede tener un programa, estarían contempladas  en ese "gap semántico" del que habla la definición de la teoría de sistemas. Son todas "propiedades debidas al soporte del modelo".

En ese caso el homomorfismo del modelo es más bien una especie de utopía, una expresión de deseos, una voluntad de exactitud más que algo exacto. Pero entonces parecería que no puede ser expresado formalmente.

Otra cuestión que me parece que hay que tener en cuenta es que muchas veces, acaso la mayoría, lo que se modela es a su vez un modelo. Si tomamos algunos de los ejemplos clásicos de las clases de programación y diseño como el de los sistemas de cuentas de banco, o los sistemas de préstamos de libros, se ve claramente que estos sistemas ya son en sí mismos un modelo.  No existen cuentas de ahorro sueltas que se relacionan con clientes, existe un modelo pensado para que el dinero circule según ciertas reglas. El problema es que se naturaliza, se reifica, (se lo considera una realidad dada) algo que es una realidad construída (un modelo).  Parece bastante claro que las "realidades" a modelar tiene distintos grados de abstracción, o si se quiere, distintas distancias con respecto a la realidad nouménica. Estos modelos informáticos serían entonces "metamodelos", con  cantidades variables de niveles "meta".

Claro que habrá ejemplos de modelos informátios que no modelan otros modelos. Tal vez sea el caso de los sistemas de simulación, que si bien pueden incluir partes que son metamodelos, el sistema total no lo es, porque lo que se aspira es que el modelo conceptual surga de algún modo de la simulación.

Revisando los usos de la palabra "modelo" encuentro que en la gran mayoría de los casos se trata de modelos teóricos; como dice la definición, sistemas abstractos que representan sistemas concretos. Excepto  los "Toy models" o los modelos del aeromodelismo o similares, los únicos modelos que además de representar algo, hacen algo, son los modelos computacionales. El modelo atómico no hace lo que hace el átomo, ni hace nada parecido, sólo busca representarlo. Para entenderlo, para enseñarlo. En cambio el software, sea que modele otros modelos, sea que modele la realidad, siempre modela para hacer algo.  Por supuesto que ese modelo puede servir también para entender o para enseñar, pero lo que nunca falta es ese hacer.

Me parece que este acento en el hacer es la clave para entender en qué se diferencia el paradigma de objetos de otros, que reducen  a abstracciones matemáticas o lógicas lo que sea que se quiere modelar, mientras que en objetos se modela a partir de lo propio de la herramienta, que es el hacer. Pues modelar un hacer  no es otra cosa que modelar comportamientos. Una forma de insistir con eso de que los objetos se definen por su comportamiento, como osadamente dije en el articulo anterior. No tengo herramientas teóricas para abordar en profundidad estos conceptos, no sé si las hay. Pero sí sé que en muchos otros ámbitos este acento en las prácticas es algo bastante reciente. Pienso por ejemplo en Roger Chartier, que viene estudiando hace tiempo la historia de los libros, de la edición, de las obras, no al modo tradicional, como estudio de técnicas y  de ideas, sino como estudio de prácticas. En lugar de la historia de las obras plantea la historia de la lectura. Valga todo esto al menos como prueba de que el paradigma de objetos está a tono con el espíritu de estos tiempos.

Volviendo entonces al problema del principio se podría decir que un buen modelo (de objetos) es un modelo en el cual hay un homomorfismo entre el comportamiento de los entes del dominio y el comportamiento de los objetos. La diferencia de esta definición es que ahora no es necesaria la correspondencia entre entidades sino entre comportamientos. Dos o más objetos pueden hacer lo que hace un ente del dominio, un objeto puede subsumir comportamientos de varios entes del dominio. Un buen navajazo de Ockham para evitar considerar las abstracciones que hemos creado como parte de un dominio que no las conocía, o recíprocamente, evitar incoporar al diseño objetos que representan entidades que sólo tiene distintos nombres, pero que se comportan del mismo modo.

Todo esto dicho también en forma osada y sujeto a revisión.