Una clase, una responsabilidad, fue uno de los textos que se me quedó grabado tras la lectura del libro Diseño Ágil con TDD de Carlos Blé.
Analizar esa simple expresión nos lleva a una regla importantísima que nos permite diseñar programas orientados a objetos y orientados a concurrencia, que sean muy óptimos y fácilmente trazables. Nos lleva a la vía en la que realizar TDD se hace obvio, y la deuda técnica desaparezca, facilitando refactorizaciones, encontrar fallos y desarrollar software con elementos pequeños, y combinando estos elementos (tal y como reza la filosofía unix) de modo que se pueda construir algo mayor, a alto nivel, sin perder el control granular de la programación a bajo y medio nivel.
Programación Orientada a Objetos
Imaginemos que tenemos que crear un programa en el que se administra un almacén. Este almacén tiene objetos que pertenecen a varias categorías, y se tiene que mantener un peticionario de las tiendas que solicitan una reposición de ciertos productos. Si lo pensamos entorno a base de datos, diagramas de Entidad/Relación (E/R), obtenemos las entidades: productos, categorías, tiendas, solicitudes; con sus respectivas relaciones.
Usando programación orientada a objetos, obtendremos que ese diagrama de clases se puede especificar muy fácilmente a través de la creación de las diferentes clases. Podemos usar algún método de persistencia, y tendremos nuestros elementos, con funcionalidad agregada dentro de cada uno de las clases, por ejemplo, en solicitudes: solicitaProducto, asociaTienda, .... ya depende de cómo lo queramos (o podamos) montar.
Ahora, si una clase como productos, de pronto agrega más funcionalidad, como por ejemplo fabricaProducto, compruebaDisponibilidad, ... podemos ver que el producto ya tiene varias responsabilidades, es decir, tendremos la propia responsabilidad de mantener los datos del producto, comprobar su caducidad, etc. a responsabilidades como fabricaProducto que debería de estar en una clase de tipo fábrica, o compruebaDisponibilidad, que debería de estar más bien en una clase de tipo almacén.
Si no respetamos esta norma, el contrato entre objetos se convierte en un auténtico caos, que puede derivar en ejecuciones difíciles de trazar y con resultados inesperados.
Programación Orientada a Concurrencia
En este caso, nos encontramos que definimos código que se ejecutará como un proceso aislado, estos códigos pueden ser, al igual que en el ejemplo anterior: productos, categorías, tiendas y solicitudes. La unidad de persistencia igualmente se puede conseguir de cualquier forma que se desee (fichero o base de datos).
En lugar de instanciar objetos, procedemos a crear procesos. Cada proceso al ejecutarse tiene su propio espacio de memoria, y de cada código específico se pueden generar tantos procesos como se necesiten. La llamada a los métodos, tal y como se llama en programación orientada a objetos: paso de mensajes; se consigue así mismo, realizando una petición o enviando un mensaje al proceso. Por lo que, por ejemplo, a un proceso de tipo solicitudes, podemos pedirle solicitarProducto, asociaTienda, ... o cualquier otra función que tenga montada el sistema.
Al igual que el caso anterior, la responsabilidad de un proceso debe de ser única. Si no se cumpliese la norma, podríamos encontrarnos con interbloqueos al intentar llamar o solicitar dos cosas al mismo proceso por bucles (o lazos) generados sin darnos cuenta.
Conclusiones
Las metodologías nos ayudan a desarrollar de una forma más organizada nuestros programas. Desarrollar software con ayuda de patrones y normas como esta, hacen que el software sea más claro y fácil de trazar, así como de ampliar y mantener. Además, estos son estándares en la industria del software, con lo que, cualquiera que conozca los patrones y normas específicas, puede entender el código y sumarse al desarrollo y ampliación del mismo sin problemas.
