En el mundo del desarrollo de software, los principios SOLID nos dicen cómo organizar funciones y datos para que nuestros códigos:

• Tolerar cambios
• Ser fácil de entender
• Ser la base de componentes que se pueden utilizar en muchos sistemas de software

El término SÓLIDO es un acrónimo de cinco postulados de diseño, que se describen a continuación:

(S) Principio de responsabilidad única: "Un módulo debe tener una y sólo una razón para cambiar"
(O) Principio abierto/cerrado: "Un artefacto de software debe estar abierto para su extensión pero cerrado para su modificación"
(L) Principio de sustitución de Liskov: "Una clase derivada debe ser reemplazable por su clase base"
(I) Principio de segregación de interfaces: "No se debe obligar a una clase a implementar interfaces y métodos que no utilizará"
(D) Principio de inversión de dependencia: "Depende de abstracciones y no de implementaciones"

SÓLIDO y GoLang

SOLID está diseñado para programación orientada a objetos y se sabe que GoLang no es un lenguaje que adopte este paradigma. Sin embargo, podemos utilizar los recursos que pone a disposición para cumplir con la metodología POO. Por ejemplo, Go no tiene soporte de herencia, pero la idea se puede compensar con su soporte de composición. De manera similar, se puede crear un tipo de polimorfismo usando interfaces.

En este artículo, el primero de una serie de 5, pretendo detallar el primer principio con ejemplos cercanos a situaciones que encontramos a diario.

Principio de Responsabilidad Única (SRP)

Ya sabemos lo que significa el término, ahora es el momento de aprender cómo implementarlo en GoLang.
En este lenguaje, podríamos definir este principio como “Una función o tipo debe tener un y solo un trabajo, y una y solo una responsabilidad”, veamos el siguiente código:

Arriba, tenemos una estructura que llamamos userService. Tiene dos propiedades: db que se encarga de comunicarse con una base de datos relacional, y amqpChannel, que permite la comunicación con el servicio de mensajería RabbitMQ.

UserService implementa un método llamado Crear. Dentro de este método almacenamos la información del usuario recibida en la base de datos y luego publicamos los datos en RabbitMQ.
Se puede ver que la responsabilidad del método Create en userService no es solo una, sino dos: almacenar información en la base de datos y publicar un mensaje en una cola RabbitMQ.

Esto puede generar varios problemas, como por ejemplo:

• Difícil de mantener: si uno de los requisitos cambia, como la forma en que se serializan los datos del usuario, tendrás que modificar la lógica del método Create, incluso si esto no tiene nada que ver con tu principal responsabilidad, que es guardar los datos en la base de datos.
• Dificultad de la prueba: como el método Create tiene dos responsabilidades diferentes, tendrás que crear pruebas para cada una de ellas, lo que puede resultar difícil y laborioso.
• Acoplamiento innecesario: la lógica de publicar datos de usuario en una cola RabbitMQ es completamente independiente de la lógica de guardar estos datos en una base de datos. Combinar estas dos responsabilidades en el mismo método crea un acoplamiento innecesario.

En el siguiente código, modificamos la estructura para respetar el SRP. Échale un vistazo:

Tenga en cuenta que hemos separado las responsabilidades en tres partes distintas: el repositorio UserRepository para conservar al usuario en la base de datos, el editor UserPublisher para enviar un mensaje a RabbitMQ y el servicio UserService que organiza estas dos operaciones.

De esta forma, cada componente se encarga de una tarea específica e independiente, facilitando el mantenimiento y evolución del código, además de permitir sustituir o mejorar cada una de estas partes sin afectar a las demás. Por ejemplo, si es necesario cambiar la base de datos utilizada, simplemente reemplace el repositorio. Si es necesario cambiar la forma de comunicación, simplemente cambie el editor.

Cabe mencionar que existe una sutil diferencia entre realizar dos tareas distintas y delegar su ejecución. En el ejemplo original de userService.Create, se realizaron dos operaciones en un solo lugar, violando el principio de responsabilidad única. Después de la refactorización, delegamos las ejecuciones a diferentes estructuras y el método Create solo fue responsable de coordinar este flujo.

Para aplicar SRP en este ejemplo, también terminamos implementando algunos de los otros principios SOLID:

• El Principio de segregación de interfaces (ISP): cada interfaz representa una única responsabilidad. Tanto UserRepository como UserPublisher son interfaces que tienen un solo método, cada uno de los cuales representa una única responsabilidad.
• El Principio de Inversión de Dependencia (DIP): la estructura userService depende de abstracciones (interfaces) y no de implementaciones concretas, es decir, no conoce la implementación específica del UserRepository y UserPublisher, solo el interfaces que implementan.
• El Principio Abierto/Cerrado (OCP): El código está abierto para extensión, ya que se pueden agregar fácilmente nuevos repositorios o editores sin modificar el servicio de usuario.

En los próximos artículos de esta serie proporcionaré una explicación más detallada de cada uno de ellos, con ejemplos específicos.

¡Hasta luego, amigos!

Referencias:
SÓLIDO: Los primeros 5 principios del diseño orientado a objetos
Blog de Clean Coder: El principio de responsabilidad única