Accesores, diseño orientado a objetos y la ley de Demeter

Acabo de leer una muy interesante entrada en el bliki de Martin Fowler (GetterEradicator) acerca de un tema muy controvertido: los accesores en programación orientada a objetos. La encapsulación, la ocultación de información, el diseño orientado al cambio, todo esto influye en la decisión de no usar get y set para todos los datos de una clase.

Tiene enlaces muy sabrosos a artículos que han ido hablando del tema, pero me gustaría destacar uno, Tell, Don't Ask en el que se habla de la "Ley de Deméter": Habla sólo con tus amigos inmediatos. Traduciendo el enunciado formal

Un método M de un objeto O solo debería invocar métodos:

• suyos
• de sus parámetros
• objetos que cree o instancie
• objetos miembros de la clase (atributos)

Así se consigue que la dependencia de la estructura entre las clases no vaya arrastrando más de un nivel. Eso si, provoca algún nivel de indirección más. Y como sabemos (Actualización:Ya decía yo que la cita la había leído hace poco... y era en Esos aparatos del demonio)

No hay ningún problema de computación que no se pueda solucionar con un nivel más de indirección (salvo si el problema es que existen demasiados niveles de indirección...)

Y claro, siempre teniendo en cuenta que toda ley o directriz de diseño debería ser eso una directriz. Siempre hay excepciones a estas reglas. El arte es saber cuando saltárselas :)

La misma entrada en BP

ACE y C++ como alternativa

A raíz de una noticia enviada a menéame, ACE contra JAVA y .NET, y que no ha pasado a portada me ha parecido necesario hacer apología de ACE. Se trata de un framework altamente portable y basado en patrones de diseño con el cual se pueden hacer aplicaciones con un uso muy facilitado de funcionalides del sistema, por ejemplo, sockets y threads, más compacto que las versiones nativas de C y por supuesto portable a un número realmente grande de plataformas.

Como todo lo bueno tiene desventajas, claro. La primera es que ocupa mucho como librería. La segunda es que no tiene GUI propio, aunque se puede usar wxWidgets, Qt, GTK+...

¿Por que no es tan conocido como otras soluciones? Mi explicación es sencilla :) No hay detrás una gran empresa con marketing, ni siquiera una fundación (creo) Su página web es fea y sin diseño y usan un lenguaje como C++ que no es lo que se lleva, aunque los apóstoles del lenguaje se empeñan, con algún éxito, de que se deje de ver a C++ como C con objetos para verlo como multiparadigma. Pero en mi opinión, y bueno, no solo en la mía, ACE da una flexibilidad y portabilidad difícilmente conseguible con otros lenguajes, frameworks o librerías

Por último nombrar alternativas en plain old C, que no he usado pero que por venir de donde vienen no deben estar mal. Serían Apache Portable Runtime y Netscape Portable Runtime usado y mantenido por Mozilla.

La misma entrada en BP

Objetos y bases de datos relacionales

Este tema da para mucho (seguro que para muchos libros y/o ríos de bytes) pero bueno, trataré de ser breve. Me he encontrado una noticia en The Server Side sobre Amber, un mapeador de objetos en bases de datos relacionales que, al contrario de el resto de estos sistemas, se centra más en las características de la base de datos, con lo que permite olvidarse de las configuraciones en XML y además dejar del lado de la base de datos, mediante procedimientos almacenados, la configuración de dicho mapeo. (Más información en Lightweight R/O Mapping y Java and the Empowered Database)

Como el tema me parece muy relevante (¿quién no programa hoy en día en un lenguaje que no soporte OO? ¿quién no usa bases de datos relacionales?) y sin embargo creo el tema no es un tema demasiado "popular" voy a tratar aportar lo que tengo a mano para aumentar la popularidad y con suerte algún lector será capaz de aportar algo más.

En la wikipedia hay una entrada acerca del mapeo O/R, que apunta a lo que me parecen dos artículos extensos y muy muy jugosos: Mapping Objects to Relational Databases: O/R Mapping In Detail y uno un poco más breve: The Object-Relational Impedance Mismatch, ambos de Scott W. Ambler. En este último se pone de relevancia algo que sospecha todo aquel que piensa detenidamente en ambos paradigmas, OO y relacional, y es que no son directamente "enchufables" y por ello se genera lo que llama impedance mismatch ("desajuste de impedancia", al parecer una analogía con la electrónica) De este desajuste se deduce que tenemos que pensar detenidamente en los mecanismos y herramientas de mapeo, no vaya a ser que nos encontremos con sutilezas desagradables en un punto más avanzado del desarrollo...

La misma entrada en BP