Hace unos años, se pusieron de moda aquellas aplicaciones que intentaban generar una aplicación a partir de sus requisitos o especificaciones. El tiempo ha pasado, y ese tipo de aplicaciones siguen pareciendo bastante improbables. Es cierto que hay herramientas capaces de generar código fuente, pero funcionan para código repetitivo y que suele escribirse siempre igual. Está claro que el desarrollo de software es un proceso muy artesanal. Depende mucho de la pericia de las personas que lo desarrollan.
Para ayudar a desarrollar programas robustos, mantenibles y que se puedan modificar, existen varios principios de diseño que ayudan a desarrollar software de este tipo. Y cómo buenos artesanos de software, son principios que deberíamos conocer.
Aunque la mayoría son aplicables a la programación orientada a objetos - el paradigma más extendido - algunos de ellos se pueden aplicar a otros tipos de programación.
No te repitas
El DRY (Don't repeat yourself) de toda la vida. Este es para mí, uno de los principios más importantes. Y además muy simple de entender. No hay que escribir código duplicado. El código duplicado es propenso a generar errores y es difícil de mantener. Si estás repitiendo código, extrae ese código a una función para encapsularlo. Si tenemos que hacer un cambio, este estará localizado en un solo punto, y no desperdigado por todo el código fuente.
Que sea simple, estúpido
Conocido como KISS (Keep It Simple Stupid). El diseño de un programa debe ser sencillo. Cuánto más sencillo sea, mejor. Hay que evitar la complejidad como norma general, pero sobre todo la complejidad innecesaria.
Aplica siempre SOLID
SOLID no es un solo principio, si no que son cinco principios. SOLID fue introducido por "Tío Bob" Martin (autor del famoso libro Clean Code, entre otros muchos) allá por el año 2000. Si como programadores somos fieles a SOLID estaremos desarrollando software más robusto. Los principios que se incluyen, son los siguientes:
Las clases o módulos deben tener una única responsabilidad
En inglés SRP (Single Responsibility Principle). Una clase o módulo debe tener una sola razón para cambiar, porque debe tener una sola responsabilidad. Además esa clase debe ser la única con esa responsabilidad. Es decir, si tenemos que cambiar una clase, que sea por una única razón.
Abierto para su extensión, pero cerrado para su modificación
El Open/Close Principle, nos dice que el código está mejor diseñado si se puede modificar su comportamiento sin cambiar su código fuente. Debería bastar con añadir código, en lugar de modificarlo. No deberíamos necesitar modificar una clase a no ser que sea para corregir errores.
El principio de sustitución de Liskov
Que yo suelo denominar como "cuidado con los pingüinos". Este principio dice que una clase derivada no debe modificar el comportamiento de la clase base. La mejor forma de entenderlo es ver cuándo no se cumple. Tenemos una clase base Ave, con el método EstablecerAltitud. Como buenos programadores, hacemos caso al principio Open / Close y creamos dos clases derivadas: Águila y Pingüino. El problema es que los pingüinos no vuelan. La clase derivada tendrá que sobreescribir el método EstablecerAltitud para no hacer nada. Al utilizar la clase Pingüino en el código, tendremos que introducir controles adicionales para no tener problemas. Es decir, si nuestra aplicación utiliza la clase Águila, esta no podrá ser reemplazada por la clase Pingüino de forma directa.
El principio de segregación de interfaces
Este principio, conocido por ISP (Interface segregation principle), dice que el una clase que implementa una interfaz no debe depender de métodos que no utiliza. Esto como norma general implica que nuestras interfaces deben ser sencillas y tener pocos métodos. Es preferible tener varias interfaces pequeñas, a tener una interfaz grande. Así no obligamos a los clientes a depender de métodos que no necesitan implementar.
El principio de inversión de dependencias
En inglés DIP (Dependency Inversion Principle), que viene a decir que las clases de alto nivel, no deben depender de clases de bajo nivel. Ambos deben depender de abstracciones. Además las abstracciones no deben depender de los detalles, si no que los detalles deben depender de las abstracciones. En definitiva, lo que tenemos que hacer es invertir las dependencias.
Por ejemplo, imaginemos una clase Saludo que tiene un método que imprime un mensaje dependiendo de la hora del día. Si es antes de las 12 de la mañana, escribe "Buenos días". Si es más tarde escribe "Buenas tardes". En este caso el componente de alto nivel es la clase Saludo, mientras que el componente de bajo nivel, es una clase Date. El método Saludar instancia un objeto de la clase Date para comprobar la hora del día y realizar el saludo que corresponda. En este caso tan simple, la clase Saludo depende de una clase de bajo nivel Date. Esto hace que, entre otras cosas, la clase Saludo sea más difícil de probar.
Si invertimos las dependencias, lo que podemos hacer es pasar un objeto Date como parámetro a la hora de instanciar la clase Saludo. Cuándo se llame al método Saludar se utilizará dicho objeto. En este caso estamos inyectando la dependencia a través del constructor de la clase Saludo.
Separa los asuntos
Principio SoC (separation of concerns). Los asuntos, son los diferentes aspectos de la funcionalidad de nuestra aplicación. Por ejemplo la capa de negocio, la capa de datos etc. Un buen ejemplo de separación es el patrón MVC.
El principio YAGNI
Muchas veces, para evitar problemas posteriores, los programadores tendemos a desarrollar funcionalidades que no estamos seguros de necesitar. Simplemente lo hacemos "por si acaso". El principio YAGNI (You ain't gonna need it), viene a decir que no debemos implementar algo si no estamos seguros de necesitarlo. Así ahorramos tiempo y esfuerzo.
La regla del Boy Scout
Como progamadores, debemos hacer como los Boy Scout, que dejan el campo más limpio que cuándo llegaron. El código siempre puede mejorar. Si podemos, debemos refactorizar el código para dejarlo todavía más limpio y simple que antes.
La Ley de Demeter
Según este principio, una unidad solo debe tener conocimiento limitado de otras unidades, y solo conocer aquellas que están relacionadas. La una unidad solo debe hablar con amigos y nunca con extraños. Además la unidad solo debe hablar con amigos inmediatos.
Simplificando mucho, tenemos que tratar de evitar utilizar métodos de un objeto que ha sido devuelto por otro método. En este caso es útil seguir la regla de nunca usar más de un punto cuando accedemos a métodos de un objeto. Por ejemplo no usar clienteActual.ObtenerDireccion.calle.CambiarNombreDeCalle. Recuerda, no hay que hablar con extraños.
El principio de Hollywood
Basado en la típica respuesta que se les da a los actores que hacen una prueba para una película: "No nos llame, nosotros le llamaremos". Este principio está relacionado con el principio de inversión de dependencias de SOLID. Un ejemplo del principio de Hollywood es la inversión de control (IoC), que hace que una clase obtenga las referencias a objetos que necesita para funcionar, a través de una entidad externa.
Estos son algunos de los más útiles o importantes, pero se pueden encontrar algunos más. Lo importante es saber en qué consiste cada principio. Así si violamos alguno de ellos, deberemos tener clara la razón que nos lleva a no cumplirlo.
En GenbetaDev | La navaja de Occam, KISS y YAGNI: la simplicidad en el código no debería ser sólo postureo developer , Solid, cinco principios básicos de diseño de clases Imagen | Ecotrust
