SRP et DIP dans Spring Boot

1. Le Principe de Responsabilité Unique (SRP)

Le SRP est sans doute le plus simple à comprendre mais aussi l'un des plus fondamentaux. Comme son nom l'indique, il stipule qu'une classe ne devrait avoir qu'une seule raison de changer.

Pour une définition claire et des exemples en Java, je vous propose de lire la ressource suivante.

Pour résumer, si une classe Employe gère à la fois les informations de l'employé ET le calcul de sa paie, elle a deux raisons de changer :

1. Une modification dans la structure des données de l'employé (ajout d'une adresse).
2. Une modification dans les règles de calcul de la paie (changement du taux de cotisation).

Le SRP nous pousse à scinder cette classe en deux : une classe Employe (un simple objet de données) et une classe PaieService (qui contient la logique de calcul).

Le SRP et l'architecture en couches

L'architecture en 3 couches que nous avons vue est une application directe du SRP à grande échelle :

• @RestController (Présentation) : Sa seule responsabilité est la communication HTTP (gérer les requêtes, sérialiser/désérialiser les DTOs, retourner les codes de statut). Elle ne devrait pas changer si une règle métier évolue.
• @Service (Métier) : Sa seule responsabilité est d'implémenter la logique métier. Elle ne devrait pas changer si on décide de passer de JSON à XML dans l'API.
• @Repository (Données) : Sa seule responsabilité est la persistance des données. Elle ne devrait pas changer si la logique de validation d'un champ métier devient plus complexe.

Quand ce principe n'est pas respecté, on se retrouve avec du code "fourre-tout" difficile à maintenir. La vidéo ci-dessous montre un exemple concret de violation du SRP dans un projet Spring.

2. Le Principe d'Inversion des Dépendances (DIP)

Maintenant que nos responsabilités sont bien séparées en couches, comment ces couches doivent-elles dépendre les unes des autres ? C'est là qu'intervient le DIP.

Le principe énonce deux choses :

1. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.
2. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

Cela peut paraître abstrait, mais l'idée est simple : dépendre d'interfaces, pas de classes concrètes.

Le Problème : Le Couplage Fort

Imaginons un ServiceCommande qui a besoin de sauvegarder des commandes en base de données. L'approche naïve serait de dépendre directement d'une classe MySQLDatabase.

Ce couplage fort est un problème majeur : si demain vous devez migrer de MySQL à PostgreSQL, ou même utiliser MongoDB (ce que vous connaissez déjà), vous devrez modifier votre ServiceCommande, qui contient pourtant la logique métier qui, elle, n'a pas changé.

La Solution : Inverser la Dépendance

Le DIP nous invite à introduire une abstraction (une interface) entre le service et la base de données.

Pour la définition formelle et un exemple simple, la ressource sur SOLID est de nouveau très pertinente.

Au lieu que ServiceCommande dépende de MySQLDatabase, on crée une interface BaseDeDonnees.

• ServiceCommande dépend maintenant de BaseDeDonnees.
• MySQLDatabase implémente l'interface BaseDeDonnees.

Le sens de la dépendance a été inversé ! Le service (haut niveau) ne dépend plus de la base de données (bas niveau). Les deux dépendent de l'abstraction BaseDeDonnees.

Le Mécanisme : L'Injection de Dépendances (DI) de Spring

C'est bien beau de dépendre d'une interface, mais à un moment, il faut bien une implémentation concrète ! Comment notre ServiceCommande obtient-il son instance de MySQLDatabase ?

C'est précisément le rôle du conteneur d'Inversion de Contrôle (IoC) de Spring, qui met en œuvre le DIP via un mécanisme appelé Injection de Dépendances (DI).

L'article suivant fait un excellent travail pour lier ces concepts.

En résumé, au lieu de faire new MySQLDatabase() dans votre service (ce qui recréerait un couplage fort), vous déclarez simplement votre dépendance à l'interface dans le constructeur, et Spring se charge de vous "injecter" l'implémentation concrète qu'il a trouvée au démarrage.

@Service
public class ServiceCommande {

    private final BaseDeDonnees db; // Dépendance à l'interface

    // Spring va injecter une classe qui implémente BaseDeDonnees
    public ServiceCommande(BaseDeDonnees db) {
        this.db = db;
    }

    public void traiterCommande(String commande) {
        // ... logique métier
        db.sauvegarderCommande(commande);
    }
}

La Preuve par l'Exemple : Une Migration sans Douleur

Revenons à la vidéo de Devoxx. Après avoir introduit l'interface, l'orateur démontre la puissance du DIP en migrant sa couche de persistance sans modifier une seule ligne de sa couche métier.

Cette démonstration est la quintessence du DIP : votre logique métier est protégée des changements techniques. Vous pouvez changer de base de données, de fournisseur d'email, de système de paiement... tant que la nouvelle implémentation respecte le contrat défini par l'interface, votre logique métier reste intacte.

Conclusion

Aujourd'hui, nous avons ajouté deux outils essentiels à votre arsenal d'architecte logiciel. Ces principes ne sont pas de la théorie obscure ; ce sont des guides pratiques pour écrire du code professionnel, maintenable et évolutif.

Les points clés à retenir :

• Principe de Responsabilité Unique (SRP) : Une classe doit avoir une seule raison de changer. C'est le principe qui motive l'architecture en couches (Controller, Service, Repository).
• Principe d'Inversion de Dépendances (DIP) : Dépendre d'abstractions (interfaces), et non d'implémentations concrètes. Cela permet de découpler les couches et de rendre le système flexible.
• Spring et le DIP : Le framework Spring est conçu autour de ce principe. Il facilite son application grâce à son conteneur IoC et au mécanisme d'injection de dépendances, de préférence par constructeur.

Dans la prochaine leçon, nous nous concentrerons sur une application spécifique de ces principes : justifier l'utilisation du pattern Repository pour l'abstraction de l'accès aux données. Vous verrez que Spring Data JPA est lui-même une magnifique illustration du DIP, vous offrant une interface (JpaRepository) pour masquer la complexité de l'implémentation sous-jacente.