¿Tu código es un "camello" de mantener? Organízalo con los Principios SOLID Básicos

Si llevas un tiempo echando código, seguro te has encontrado con ese temido momento: te piden un cambio pequeño en una función y, de la nada, se daña la mitad de la aplicación. Te toca quedarte hasta tarde resolviendo un chicharrón que ni sabías de dónde salió.

Para que el desarrollo no se vuelva un "camello" indomable, la comunidad de software utiliza una guía clave: los principios SOLID. Aunque suenan muy teóricos, hoy vamos a bajarlos a la tierra con plastilina y ejemplos claros para que empieces a aplicarlos desde ya.

¿Qué es SOLID?

SOLID es un acrónimo inventado por Robert C. Martin ("Uncle Bob") que reúne cinco buenas prácticas de la programación orientada a objetos. Su objetivo principal es ayudarnos a escribir código limpio, fácil de entender y, sobre todo, fácil de cambiar en el futuro.

Vamos a ver los tres primeros principios, que son el mejor punto de partida para cualquier desarrollador.

1. S: Principio de Responsabilidad Única (Single Responsibility Principle)

La regla de oro: Una clase o módulo debería tener una sola razón para cambiar.

En Colombia nos encanta el "todero" (el que arregla la luz, pinta, sabe de plomería y arregla el carro), pero en el código, los toderos son un peligro. Si tienes una clase que se encarga de calcular un reporte, darle formato a un PDF y además guardarlo en la base de datos, estás rompiendo este principio.

• El problema: Si mañana cambia la forma de conectar la base de datos, podrías dañar sin querer la lógica que calcula el reporte.

• La solución: Divide y vencerás. Crea una clase para el cálculo, otra para generar el PDF y otra para la base de datos. Cada una a lo suyo.

2. O: Principio de Abierto/Cerrado (Open/Closed Principle)

La regla de oro: El software debe estar abierto para la extensión, pero cerrado para la modificación.

Imagina que estás construyendo una pasarela de pagos para un e-commerce y configuras todo para recibir pagos con Efecty. Semanas después, el cliente te dice: "Oiga, ahora necesitamos recibir Nequi y Daviplata".

Si para meter Nequi te toca abrir el archivo original y meter un montón de condicionales (if/else), estás rompiendo el principio.

• La solución: Diseña tu código usando interfaces o clases abstractas. Creas una estructura general para "PasarelaDePago". Cuando llegue Nequi, simplemente creas un archivo nuevo que extienda de esa estructura. El código viejo no se toca (cerrado a modificación), pero la aplicación crece sin problema (abierta a extensión).

3. L: Principio de Sustitución de Liskov (Liskov Substitution Principle)

La regla de oro: Si tienes una clase hijo, deberías poder usarla en lugar de la clase padre sin que todo se rompa.

Este principio nos dice que la herencia debe ser real y lógica. Piensa en esto: una empresa de envíos tiene una clase padre llamada VehiculoDeReparto. De ahí heredan Camion y Motocicleta. Ambos pueden acelerar, frenar y llevar paquetes. Todo bien.

Pero si creas una clase Dron De Reparto y resulta que no implementa el método encenderMotor() igual porque funciona con batería digital o no usa la misma lógica de rutas terrestres, podrías generar un error cuando el sistema intente manejar el dron como si fuera un camión.

• En cristiano: Las clases hijas no deben decepcionar las expectativas que dejó la clase padre. Tienen que ser capaces de hacer lo mismo que el padre promete.

4. I: Principio de Segregación de Interfaces (Interface Segregation Principle)

La regla de oro: Es mejor tener muchas interfaces específicas que una sola interfaz general "todera". Nadie debería estar obligado a depender de métodos que no usa.

Imagina que creas una interfaz llamada Trabajador. Como estás pensando en un equipo grande, le pones los métodos programar(), disenarInterface() y venderProyecto().

Si creas una clase para un desarrollador backend y le implementas esa interfaz, el sistema lo va a obligar a escribir código para disenarInterface() y venderProyecto(). ¿Qué va a terminar pasando? Que el desarrollador va a dejar esos métodos vacíos o sacando un error porque esa no es su labor.

• La solución: Segmenta. En lugar de una interfaz gigante, crea tres pequeñas: Programable, Disenable y Vendible. Así, cada clase implementa solo lo que realmente sabe y necesita hacer. No pongas a tu código a cargar con obligaciones ajenas.

5. D: Principio de Inversión de Dependencias (Dependency Inversion Principle)

La regla de oro: Los módulos de alto nivel no deben depender de módulos de bajo nivel; ambos deben depender de abstracciones. Además, las abstracciones no deben depender de los detalles.

Este suena como un trabalenguas, pero se entiende muy fácil con un ejemplo del mundo real. Piensa en los tomacorrientes de las paredes de tu casa. La empresa de energía te da una abstracción (el enchufe estándar). A ti no te importa si detrás de la pared hay cables de cobre, de aluminio, o si la luz viene de una hidroeléctrica o de paneles solares (esos son los detalles de bajo nivel). Tú solo conectas tu cargador y funciona.

En el software es igual. Si tienes una clase de alto nivel como ProcesarPedido, esta no debería depender directamente de una clase de bajo nivel llamada EnviarCorreoConMailgun.

• El problema: Si el día de mañana Mailgun sube los precios y te toca cambiar a Amazon SES, vas a tener que modificar la lógica de los pedidos, arriesgándote a dañar el negocio por un cambio de proveedor.

• La solución: Haz que ProcesarPedido dependa de una interfaz genérica llamada ServicioDeCorreo. Así, cambias el proveedor abajo (en el detalle) las veces que quieras, y tu lógica principal (el pedido) ni se entera ni se rompe.

¿Por qué deberías empezar a usarlos?

Al principio, aplicar SOLID puede dar la impresión de que estás escribiendo más archivos de la cuenta o dando muchas vueltas. Sin embargo, la recompensa llega muy rápido:

• Menos dolores de cabeza: Encontrar un bug es mil veces más fácil cuando cada archivo hace una sola cosa.

• Trabajo en equipo fluido: Tus compañeros de equipo entenderán tu código a la primera, sin necesidad de que les des una exposición de dos horas.

• Código que escala: Tu proyecto puede crecer de un MVP básico a una plataforma robusta sin que sientas que la estructura se va a caer en cualquier momento.

Escribir código que funcione lo hace cualquiera; escribir código que dure y sea un gusto mantener, eso es lo que define a un verdadero profesional.

¡A ponerlos en práctica en los proyectos de esta semana!