Thursday, December 13, 2007

Acoplamiento y No Convexidad

Disclaimer:
  • Este articulo tenia ganas de escribirlo hace un tiempo, pero habia un par de cosas que no me cerraban del todo, y queria esperar a que tenga el concepto cerradito y monono. Eso no paso, pero lo que si paso fue que me canse.
  • Este es un articulo computronico
Lo que queria hacer era relacionar funciones, metodos, clases,  y namespaces con conjuntos.
Supongamos que tenemos una clase que sea una estacion climatica. Esta estacion climatica tiene sensores, como por ejemplo, termometros. 
Nosotros somos consumidores exernos de informacion, y solamente nos interesa lo
 que la estacion climatica nos puede ofrecer.




La imagen anterior vendria a ser una representacion de nuestro mundo.
A travez de los metodos, se producen relaciones entre los objetos.
Por ejemplo, si el consumidor externo quiere saber la temperatura, le pregunta a la estacion climatica la temperatura, se produce una relacion entre el consumidor y la estacion climatica.
Como la clase que define el consumidor tiene como variable de instancia una estacion climatica, la relacion ya esta establecida en la propia clase, por lo tanto, la relacion que genera el metodo es una relacion que va de la clase a la clase. 
A pesar de que por claridad yo dibuje las flechitas como saliendo de las clases, cuando estos nos encontramos con estos metodos, en realidad lo que ocurre es que todas las relaciones se producen dentro del conjunto que define la clase. Lo que se parece bastante al concepto de convexidad.

Por otro lado, puede ocurrir que el consumidor externo, en vez de preguntarle a la estacion climatica la temperatura, le pida su sensor de temperatura, y a la vez a este le pida la temperatura actual.
Esto es lo que vemos en este grafico:




En este caso, la relacion que generaria el metodo para obtener la informacion de la temperatura, iria mas alla de lo que define el conjunto de la clase consumidor externo (aunque volveria al consumidor externo, "salio por un rato" para buscar la temperatura).
Si trazacemos las flechas que define las relaciones producidas por este metodo, veriamos que pasa por la clase "sensor de temperatura", el cual no es conocido por el consumidor externo.
En este caso, las relaciones son relaciones no convexas, y por otro lado, este es un buen ejemplo de alto acoplamiento entre clases.
En que sentido esto no esta piola? 
Bueno, si por ejemplo cambiamos el sensor de temperatura por uno construido en el imperio, con las temperaturas medidas en grados farengein, en vez de en grados celcios, tendriamos un gran problema, ya que el consumidor externo no sabria nada sobre eso (problema que seguro estaria resuelto por la estacion climatica).

Por otro lado, hay algo interesante. A pesar de que estas tres clase estan acopladas entre si, las relaciones que producen sus metodos se mantienen dentro del conjunto definido por esas tres clases.
Si quisieramos definir un namespace que englobe esas tres clases, podriamos hacerlo, y tendriamos las caracteristicas de convexidad para ese namespace. 
Por lo que estariamos encapsulando este micromundo en ese namespace. Y maravillosamente, el minimo conjunto convexo que contiene a una serie de puntos se llama capsula convexa (o clausura convexa), por lo que el nombre de encapsulamiento parece tener aun mas sentido :)

Bueno, espero que a alguien le guste este post, a mi realmente no me gusta, pero ya no queria pensar mas en esto, y esta es la mejor manera de sacar un tema de la cabeza :)

saludos
/jb 

3 comments:

Anonymous said...

No es que no me guste, pero no entendí. Entiendo la parte de la estación climatica y el problema de acoplamiento, es más es algo que me interesa mucho. Pero lo demás no logro entenderlo me falta contexto.
Encontraste una analogía matemática a la dependencia de clases? algo que ayuda a resolver problemas con estas?

jb said...

Claro, un poco eso era la idea.
La analogia existe entre no-convexidad y acoplamiento.
Creo que ese es un primer punto de partida (tambien hay como una definicion implicita de lo que es un conjunto -y va a seguir siendo implicita por que no lo voy a defnir -).
Creo que puede ayudar a resolver (o evitar) problemas a travez de analisis estatico, cuando el lenguaje usa static typing, o analisis dinamico en caso contrario.
Que es lo que habria que buscar? Bueno, la idea seria graficar las capsulas convexas. En el caso en que estas tengan un nivel demasiado grande (abarquen, por ejemplo, muchas clases), es que estamos teniendo un problema de acoplamiento bastante fuerte.

Igual, esto no ve el 100% de los casos donde el alto acoplamiento puede ocurrir.
Por ejemplo, si la clase consumidor tiene un miembro explicito que es el termometro, esa relacion explicita no se puede diferenciar de esta manera cuando esta produciendo un alto nivel de acoplamiento, y cuando no

Anonymous said...
This comment has been removed by a blog administrator.