Diseño orientado a interfaces (parte I)

Las interfaces surgen como una evolución de la Programación Orientada a Objetos con la necesidad de agrupar y reutilizar las distintas funcionalidades de un objeto en una interfaz más manejable. El diseño Orientado a interfaces pretende que el desarrollo del software genere implementaciones de programas bien estructurados. Mediante las interfaces, podremos crear mejores diseños sin basarnos tanto en la POO. Podemos encontrar una buena explicación sobre este tipo de programación en el libro Interface-OrientedDesign , donde Ken pugh nos hace una muy buena argumentación del porqué debemos utilizar mas las iterfaces para mejorar nuestro diseño y evitar los anti-patrones de diseño sobre OO como por ejemplo utilizar demasiado la herencia, fuerte acoplamiento, etc. La lista de los anti-patrones la podéis encontrar en la wikipedia. Una de las cosas que más me ha gustado sobre el libro, es el capítulo sobre los contratos de las interfaces y sobre las 3 leyes que deben cumplir las interfaces. Estas 3 leyes se basan en las 3 leyes de la robótica por Isaac Asimov (si recordáis la película Yo, Robot, allí se mencionaban). Estas 3 leyes son las siguientes:

1. Un robot no puede hacer daño a un ser humano o, por su inacción, permitir que un ser humano sufra daño.
2. Un robot debe obedecer las órdenes dadas por los seres humanos, excepto si estas órdenes entrasen en conflicto con la Primera Ley.
3. Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la Primera o la Segunda Ley.

Bien, como se comentan en estas 3 leyes, algo parecido le ocurre a las interfaces, donde el autor comenta:

1. La implementación de una interfaz debe hacer lo que sus métodos dicen que hacen.

Esta ley indica que los nombres de los métodos deben corresponder a la acción que hacen, y que cada método debe devolver un valor que indique si la operación ha tenido éxito o si al contrario hay error.

2. Una interfaz no debe interferir otros módulos de un programa o con otros programas.

En este caso, se expone que una interfaz no debe utilizar recursos de otros módulos, es decir si uno de los propósitos de la interfaz es leer un dato de un fichero, no necesita una conexión a una base de datos.

3. Si una implementación no es capaz de realizar su responsabilidad, debe notificar a quien lo llamó.

La implementación debe reportar siempre el problema que encuentra, si no es capaz de realizar la acción, debe informar a su creador o invocador e informarle del problema mediante un código de error o un estado.

La verdad es que este tipo de diseño, abre un nuevo camino a explorar y sobretodo permite comprobar si el diseño de nuestras aplicaciones es correcto o no desde el punto del aprovechamiento de las propiedades de la OO, sabiendo aplicar correctamente la herencia, el polimorfismo, etc.

En un segundo post, pondré varios ejemplos utilizando las interfaces con los diferentes patrones de diseño que se utilizan.