Dans le monde du développement logiciel, les principes SOLID nous indiquent comment organiser les fonctions et les données afin que nos codes :

• Tolérer les changements
• Soyez facile à comprendre
• Être la base de composants pouvant être utilisés dans de nombreux systèmes logiciels

Le terme SOLID est un acronyme désignant cinq postulats de conception, décrits ci-dessous :

(S) Principe de responsabilité unique : "Un module doit avoir une et une seule raison de changer"
(O) Principe ouvert/fermé : "Un artefact logiciel doit être ouvert pour extension mais fermé pour modification"
(L) Principe de substitution de Liskov : "Une classe dérivée doit être remplaçable par sa classe de base"
(I) Principe de ségrégation des interfaces : "Une classe ne doit pas être obligée d'implémenter des interfaces et des méthodes qu'elle n'utilisera pas"
(D) Principe d'inversion des dépendances : "Dépend des abstractions et non des implémentations"

SOLIDE et GoLang

SOLID est conçu pour la programmation orientée objet, et on sait que GoLang n'est pas un langage qui adopte ce paradigme. Cependant, nous pouvons utiliser les ressources qu'il met à disposition pour répondre à la méthodologie POO. Par exemple, Go n'a pas de support d'héritage, mais l'idée peut être compensée par son support de composition. De même, un type de polymorphisme peut être créé à l'aide d'interfaces.

Dans cet article, le premier d'une série de 5, je compte détailler le premier principe avec des exemples proches des situations que nous rencontrons au quotidien.

Principe de responsabilité unique (SRP)

Nous savons déjà ce que signifie le terme, il est maintenant temps d'apprendre comment l'implémenter dans GoLang.
Dans ce langage, on pourrait définir ce principe comme « Une fonction ou un type doit avoir un et un seul travail, et une et une seule responsabilité », voyons le code suivant :

Ci-dessus, nous avons une structure que nous appelons userService. Il possède deux propriétés : db qui est responsable de la communication avec une base de données relationnelle, et amqpChannel, qui permet la communication avec le service de messagerie RabbitMQ.

UserService implémente une méthode appelée Create. Dans le cadre de cette méthode, nous stockons les informations utilisateur reçues dans la base de données, puis publions les données sur RabbitMQ.
On peut voir que la responsabilité de la méthode Create dans userService n'est pas une, mais deux : stocker les informations dans la base de données et publier un message dans une file d'attente RabbitMQ.

Cela peut entraîner plusieurs problèmes, tels que :

• Difficile à maintenir : si l'une des exigences change, comme la façon dont les données utilisateur sont sérialisées, vous devrez modifier la logique de la méthode Create, même si cela n'a rien à voir avec votre responsabilité principale, qui est de enregistrez les données dans la base de données.
• Difficulté des tests : comme la méthode Create a deux responsabilités différentes, vous devrez créer des tests pour chacune d'elles, ce qui peut être difficile et laborieux.
• Couplage inutile : la logique de publication des données utilisateur dans une file d'attente RabbitMQ est totalement indépendante de la logique de sauvegarde de ces données dans une base de données. Mélanger ces deux responsabilités dans la même méthode crée un couplage inutile.

Dans le code suivant, nous modifions la structure pour respecter le SRP. Vérifiez-le:

Notez que nous avons séparé les responsabilités en trois parties distinctes : le référentiel UserRepository pour conserver l'utilisateur dans la base de données, l'éditeur UserPublisher pour envoyer un message à RabbitMQ et le service UserService qui orchestre ces deux opérations.

De cette manière, chaque composant est responsable d'une tâche spécifique et indépendante, facilitant la maintenance et l'évolution du code, en plus de permettre de remplacer ou d'améliorer chacune de ces parties sans affecter les autres. Par exemple, s’il est nécessaire de changer la base de données utilisée, remplacez simplement le référentiel. S'il est nécessaire de changer de forme de communication, il suffit de changer d'éditeur.

Il convient de mentionner qu'il existe une différence subtile entre effectuer deux tâches distinctes et déléguer leur exécution. Dans l'exemple original de userService.Create, deux opérations ont été effectuées au même endroit, violant le principe de responsabilité unique. Après le refactoring, nous avons délégué les exécutions à différentes structures et la méthode Create était uniquement responsable de la coordination de ce flux.

Pour appliquer SRP dans cet exemple, nous avons également fini par mettre en œuvre certains des autres principes SOLID :

• Le Principe de ségrégation des interfaces (ISP) : chaque interface représente une responsabilité unique. UserRepository et UserPublisher sont des interfaces qui n'ont qu'une seule méthode, chacune représentant une seule responsabilité.
• Le Principe d'inversion de dépendance (DIP) : la structure userService dépend d'abstractions (interfaces) et non d'implémentations concrètes, c'est-à-dire qu'elle ne connaît pas l'implémentation spécifique de UserRepository et UserPublisher, seulement le interfaces qu'ils implémentent.
• Le Principe ouvert/fermé (OCP) : le code est ouvert à l'extension, car de nouveaux référentiels ou éditeurs peuvent être facilement ajoutés sans modifier userService.

Dans les prochains articles de cette série, je fournirai une explication plus détaillée de chacun d'eux, avec des exemples spécifiques.

À plus tard, les amis !

Les références:
SOLID : les 5 premiers principes de la conception orientée objet
Clean Coder Blog - Le principe de responsabilité unique