In the world of software development, SOLID principles tell us how to organize functions and data so that our codes:

• Tolerate changes
• Be easy to understand
• Be the basis of components that can be used in many software systems

The term SOLID is an acronym for five design postulates, described below:

(S) Single Responsibility Principle: "A module must have one and only one reason to change"
(O) Open/Closed Principle: "A software artifact must be open for extension but closed for modification"
(L) Liskov Substitution Principle: "A derived class must be replaceable by its base class"
(I) Interface Segregation Principle: "A class should not be forced to implement interfaces and methods that it will not use"
(D) Dependency Inversion Principle: "Depend on abstractions and not implementations"

SOLID and GoLang

SOLID is designed for object-oriented programming, and it is known that GoLang is not a language that adopts this paradigm. However, we can use the resources it makes available to meet the OOP methodology. For example, Go does not have inheritance support, but the idea can be compensated with its composition support. Similarly, a type of polymorphism can be created using interfaces.

In this article, the first in a series of 5, I intend to detail the first principle with examples that are close to situations we encounter on a daily basis.

Single Responsibility Principle (SRP)

We already know what the term means, now it's time to learn how to implement it in GoLang.
In this language, we could define this principle as “A function or type must have one and only one job, and one and only one responsibility”, let's see the following code:

Above, we have a struct we call userService. It has two properties: db which is responsible for communicating with a relational database, and amqpChannel, which enables communication with the RabbitMQ messaging service.

UserService implements a method called Create. Within this method we store the received user information in the database and then publish the data to RabbitMQ.
It can be seen that the responsibility of the Create method in the userService is not just one, but two: storing information in the database and publishing a message in a RabbitMQ queue.

This can lead to several problems, such as:

• Difficult to maintain: if one of the requirements changes, such as the way user data is serialized, you will have to modify the logic of the Create method, even if this has nothing to do with your main responsibility , which is to save the data in the database.
• Test difficulty: as the Create method has two different responsibilities, you will have to create tests for each of them, which can be difficult and laborious.
• Unnecessary coupling: the logic of publishing user data to a RabbitMQ queue is completely independent of the logic of saving this data to a database. Mixing these two responsibilities in the same method creates unnecessary coupling.

In the following code, we modify the structure to respect the SRP. Check it out:

Note that we have separated the responsibilities into three distinct parts: the repository UserRepository to persist the user to the database, the publisher UserPublisher to send a message to RabbitMQ, and the service UserService which orchestrates these two operations.

In this way, each component is responsible for a specific and independent task, facilitating the maintenance and evolution of the code, in addition to allowing each of these parts to be replaced or improved without affecting the others. For example, if it is necessary to change the database used, simply replace the repository. If it is necessary to change the form of communication, simply change the publisher.

It is worth mentioning that there is a subtle difference between performing two distinct tasks and delegating their execution. In the original example of userService.Create, two operations were performed in one place, violating the principle of single responsibility. After refactoring, we delegated executions to different structs and the Create method was only responsible for coordinating this flow.

To apply SRP in this example, we also ended up implementing some of the other SOLID principles:

• The Interface Segregation Principle (ISP): each interface represents a single responsibility. Both UserRepository and UserPublisher are interfaces that have only one method, each representing a single responsibility.
• The Dependency Inversion Principle (DIP): the userService struct depends on abstractions (interfaces) and not on concrete implementations, that is, it does not know the specific implementation of the UserRepository and UserPublisher, only the interfaces that they implement.
• The Open/Closed Principle (OCP): The code is open for extension, as new repositories or publishers can be easily added without modifying userService.

In the next articles in this series I will provide a more detailed explanation of each of them, with specific examples.

See you later, folks!

References:
SOLID: The First 5 Principles of Object Oriented Design
Clean Coder Blog - The Single Responsibility Principle