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