Principios del diseño de software
Los principios de diseño de software son como una guia que nos ayuda dando pautas para el desarrollo de estas aplicaciones.
A diferencia de los patrones de diseños, los principios no proveen con pasos, situaciones donde aplicarlos, es un poco mas generico.
Alguno de estos principios son siglas en ingles, obviamente, y son autoexplicativos. Alguno de ellos son kiss dry yagni soc solid.
Kiss (Keep it simple, stupid)
"Mantenelo simple corazón", esa es mi traducción por lo del beso y el corazón, aun que no haga falta ser bilingue para saber a que ser refiere la ultima S.
Otra variante podría ser invertir la palabras finales resultando ser "Mantenelo estupidamente simple" (keep it stupid simple) Este principio nos dice que tanto la documentación, el diseño, el código debe ser tan simple como sea posible, como si se tratará de leer una guia a prueba de tontos. Evitando la sobre-complicacíon cuando ésta sea innecesaria.
Luego de algún tiempo programando tendemos a aplicar nuestra experiencia resolviendo cuestiones no solicitadas, por ejemplo crear un formulario para visualizar datos existentes en una base de datos y queremos realizar una progresive web app con soporte de multilenguaje y personalización de estilos en tiempo de ejecución, con un backend con una arquitectura de microservicios, con servidores de descubrimiento, servidor de para balancear la carga, otro para estadisticas y métricas, montado sobre contenedores... y en fin muchas herramientas cuando existen alternativas mas sencillas.
Este es el principio más dificil de seguir en terminos de escalabildad. Por que nuestra solución sencilla es ideada para unos pocos usuarios, pero nuestro cliente confia que pronto tendrá cientos o miles de usuarios y pronto serán usuarios insatisfechos quejandose de lo lenta que resulta la herramienta que creamos manteniendo las cosas lo mas simple posible.
Será nuestra visión la que determine hasta donde se pueden mantener las cosas simples
DRY (Don’t Repeat Yourself))
O en español SECO (Siempre evita codigo oscuro), la máxima de este principio es evitar el uso del CTRL+C + CTRL+V, repitiendo funcionalidades entre distintas clases o métodos, ya que esto haria que el proyecto en general tenga mas lineas de codigo, sea dificil de entender y de mantener.
SOLID
- Single Responsibility
- Open/Closed
- Liskov Sustitution
- Interface segregation
- Dependency inversion
A este principio le pusieron unas solidas ganas, introducido por Robert C. Martin y sus siglas agrupan otros 5 principios de la programacion orientada a objetos.
Single Responsibility, el principio de responsabilidad unica nos dice que una pieza de codigo tiene que tener una unica responsabilidad. Ese metodo getUsuario(id) deberia obtener un usuario por su id, o almenos eso se espera de el, pero si al inspeccionar de cerca el metodo nos damos cuenta que obtiene el usuario, actualiza la fecha de ultima actividad y le envia un mail con las novedades claramente estaria violando este principio, haciendo a la aplicacion dificil de entender por su impredictibilidad. Lo mas razonable sea contar con otros metodos como actulizarUltimaActividad(usuario) y informarNovedades(usuario) que se encarguen de una sola cosa.
Open/Closed, el principio de Abierto/Cerrado nos dice que una pieza de codigo tiene que estar abierta a extensiones pero cerrada al modificaciones. Este principio esta destinado a clases que puedan ser heredadas, donde sus clases hijas puedan extender su funcionalidad, pero sin cambiar lo que existia.
Liskov sustitution, el principio de sustition de Liskov nos dice que cada clase puede ser sustituida en lugar de su padre, sin la necesidad de conocer cual se esta implementando. Esto pasa generalmente al usar colecciones, definimos un objeto tipo List aunque la implementacion podria ser ArrayList, LinkedList.
Interface segregation, el principio de segregacion de interfaces dice que el codigo cliente no debiera estar atado a funcionalidades innecesarias al implementar una interfaz, esta no debe segregar metodos de proposito general. Una solucion a este problema es romper la interfaz en varias interfaces mas pequeñas y mas especificas. Otra solucion es el patron adapter, que permite heredar de una clase que implementa una interfaz extensa
Dependency inversion, el pricipio de inversion de dependencia nos dice que se debe depender de abstracciones y no de implementaciones, desacoplando asi los modulos de alto nivel de los modulos de bajo nivel. La Inyección de Dependencias es uno de los métodos que siguen este principio.
YAGNI (You aren’t gonna need it)
El principio de lo no vas a necesitar tiene su origen en la programación extrema, y propone evitar aquellas piezas de codigo que se desarrollan por si acaso, generalmente sobrevalidaciones, sin estar seguros de necesitarlo y nos dice no, no lo vas a necesitar.
SOC (Separation of concern)
El principio de separacion de conceptos nos habla de 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(Modelo, vista, controlador).
The Boy Scout rule
Este no es un acronimo, si lo fuese seria TBSR, pero basicamente nos propone aplicar la regla del boyscout, dejar el campo en mejores condiciones de lo que lo encontamos. Como desarrolladores siempre se puede hacer un pequeño cambio para mejorar la calidad de nuestro codigo, algo que veamos al pasar y que estamos seguros que podemos mejorar, siempre y cuando este no sea un cambio.
La Ley de Demeter
Según este principio, una pieza de codigo solo debe tener conocimiento limitado de otras piezas de codigo, y solo conocer aquellas que con las que está relacionadas. Es como aquella frase que dice nunca hables con extraños, podriamos agregar con amigos cerrcanos.
El principio de Hollywood
Este principio está basado en la típica respuesta que se les da a los actores que hacen una audicion para una película: "No nos llame, nosotros le llamaremos". 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 poder funcionar, a través de una entidad externa, como el contenedor de Spring.
