Aprende los principios SOLID por el bien de todos

Hoy vamos a ver qué son y qué beneficios nos aportan los principios SOLID de los que tanto hablo en YouTube y en las entradas del blog.

Desde mi punto de vista, la diferencia entre un programador que aplica SOLID y otro que no es enorme. Puede ser la diferencia entre un programador junior y un programador intermediate, y un conocimiento necesario para considerarse senior.

En un post anterior vimos como SOLID te podría dar una gran flexibilidad a tu código siguiendo solo 2 de los 5 principios, imagínate si los seguimos todos.

¿Qué son los principios SOLID y que nos aportan?

Los principios SOLID son 5 normas de distintos autores, entre ellos Robert C. Martin, también conocido como el tío Bob, que para quien no lo conozca es un programador que lleva más de 50 años trabajando en el software, así que algo podremos aprender de él.

Pues tanto él como otros, crearon una serie de normas con el objetivo de ayudarnos a desarrollar un código más flexible y mantenible.

Créeme cuando te digo que realmente hay una diferencia abismal entre un proyecto grande que sigue SOLID y otro que no lo sigue. Tanto a nivel de costes de desarrollo porque no es lo mismo tardar 1 semana que 3, como a nivel emocional de los trabajadores, ya que a nadie le gusta arreglar una cosa y romper dos, o tener que ingeniárselas para añadir un cambio dentro del sistema sujetándolo con pinzas para no tenerlo que cambiar todo.

Esto que os he mencionado acaba desembocando en frustración y en pérdida del interés por el proyecto, y a la larga por nuestra pasión por el desarrollo de videojuegos, créeme porque lo he vivido personalmente.

Principio de responsabilidad única – Single Responsibility Principle

Lo que viene a decir este principio es que un objeto debe de tener un único motivo de cambio, una única responsabilidad, entendiendo por objeto tanto una clase como un módulo, o incluso una función.

Por ejemplo, si tenemos una clase Hero que gestiona la vida, el ataque del héroe, el movimiento, etc. esto está incumpliendo el primer principio y a la larga nos traerá problemas.

El principal problema de no cumplir este principio es que nuestro código se hace difícil de seguir y de cambiar porque está todo acoplado entre sí, lo que acaba provocando daños colaterales, cambiamos una cosa y rompemos otra.

Principio SOLID - Single Responsibility Principle

Principio de Abierto-Cerrado – Open-Close Principle

Este principio SOLID nos dice que nuestras entidades o clases deben de estar abiertas a la extensión y cerradas a la modificación, lo que viene a significar que para extender nuestro sistema no deberíamos de necesitar modificar las clases ya existentes.

Por ejemplo, si tenemos varios power-ups, no puede ser que para añadir un nuevo power-up tengamos que cambiar el código que instancia estos objetos, un patrón que viene muy bien para solventar esto es el Factory Method que ya vimos en otra entrada.

No cumplir con este principio ralentizará el equipo y nos obligará a tener que estar constantemente modificando sistemas que en principio estaban terminados. Además si contamos con un servidor este problema aún se agrava más.

Principio de sustitución de Liskov – Liskov Substitution Principle

Este principio dice que los objetos deberían de poder ser reemplazados por instancias de sus subclases sin que el programa deje de funcionar.

Por ejemplo, si tenemos una clase Cuadrado que hereda de Rectángulo, en cualquier momento deberíamos de poder trabajar con rectángulos directamente en lugar de con cuadrados, si no es así nos tenemos que replantear esa herencia.

Incumplir este principio nos puede llevar a tener errores silenciosos, ya que estaremos utilizando una clase que no estaba preparada para ser utilizada de esa forma (y nadie está impidiendo que lo hagamos). Los errores que provoca no son fácilmente visibles, a no ser que hayamos tomado las precauciones de llenar todo nuestro código de asserts y throws.

A esto se le llama programación a la defensiva y no es la mejor opción.

Principio SOLID - Liskov Substitution Principle

Principio de segregación de interfaces – Interface Segregation Principle

El penúltimo de los principios SOLID viene a decir que es mejor tener muchas interfaces con pocas funciones que una única interfaz con muchas funciones.

De primeras puede resultar extraño: ¿porque tener muchas interfaces si puedo tener solo una y tenerlo centralizado? ¿Y para qué necesito interfaces si solo aportan complejidad?

Por desgracia esta afirmación no es cierta, utilizar interfaces nos aportará muchísimo, y con el patrón Adapter podéis ver un pequeñísimo ejemplo de esto.

Estas afirmaciones son el reflejo de un problema mayor, que suele ser, un código mal estructurado (que no sigue SOLID), utilizar nombres vacíos o con poca riqueza de significado como «manager», no utilizar una arquitectura, o no tener una buena jerarquía de directorios.

Principio de inversión de dependencias – Dependency Inversion Principle

Para terminar tenemos el principio de inversión de dependencias que dice algo tan simple como que debemos de depender de abstracciones y no de concreciones, esto quiere decir que es mejor depender de clases abstractas e interfaces que de clases concretas.

Hacer esto nos permitirá en cualquier momento reemplazar una clase por otra y extender el sistema sin tener que cambiar prácticamente nada, lo que apoya y mucho a los principios anteriores.

Conclusión

Estas simples normas son los principios SOLID y nos ayudan enormemente a crear un código más extensible y mantenible. De ti depende ahora aprender más sobre estoy y empezar a aplicarlo en tu código. Para esto tienes multitud de cursos y material online en internet.

Otras entradas

Resumen
➤ Aprende los principios SOLID por el bien de todos
Nombre del artículo
➤ Aprende los principios SOLID por el bien de todos
Descripción
Los principios SOLID te ayudarán a POTENCIAR 🚀 tu carrera haciendo un CÓDIGO más FLEXIBLE y MANTENIBLE utilizando técnicas ya contrastadas 😎.
Autor
Publisher Name
The Power Ups - Learning
Publisher Logo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *