Responsabilités et cohésion

Objectifs

À la fin de cette leçon, vous saurez :

• reconnaître la classe fourre-tout et ses symptômes ;
• découper selon des responsabilités cohérentes ;
• équilibrer cohésion (forte) et couplage (faible).

L'anti-pattern : UserManager

class UserManager {
  creerUtilisateur() { ... }
  envoyerEmail() { ... }
  sauvegarderEnBase() { ... }
  genererPdf() { ... }
  calculerStatistiques() { ... }
}

Symptômes de cette classe malade :

• son nom contient Manager ou Utils : personne ne sait ce qu'elle fait ;
• elle change pour dix raisons différentes : email, PDF, base...
• ses tests exigent de mocker tout l'univers ;
• tout le monde la modifie → conflits Git permanents.

La découpe par responsabilités

UserService        → règles métier des utilisateurs
EmailService       → envoi d'emails
UserRepository     → accès base aux données utilisateur
PdfService         → génération de documents

Chaque classe répond à UNE question : « que se passe-t-il quand on crée un utilisateur ? » devient une orchestration :

class UserService {
  constructor(repo, emails) {
    this.repo = repo;
    this.emails = emails;
  }

  async inscrire(donnees) {
    const user = await this.repo.creer(donnees);
    await this.emails.bienvenue(user.email);
    return user;
  }
}

Le service coordonne ; il ne sait NI comment on insère en base, NI comment partent les mails.

Cohésion et couplage

Deux mesures mentales du design :

COHÉSION   = les éléments d'une classe ont-ils une raison commune d'exister ?
             forte  → EmailService ne parle que d'emails
             faible → UserManager mélange tout

COUPLAGE   = combien de modules connaissent les détails des autres ?
             faible → UserService dépend de "quelque chose qui envoie des mails"
             fort   → chaque classe importe directement toutes les autres

Cible perpétuelle : forte cohésion, faible couplage. Chaque module est compréhensible seul, remplaçable sans effet domino.

Le test de la phrase

Décrivez votre classe en UNE phrase sans « et » :

• « Envoie des emails transactionnels. » ✅
• « Gère les utilisateurs et leurs emails et leurs documents et... » ❌ → découpez.

Exercice

1. Découpez UserManager ci-dessus : listez classes, responsabilités, dépendances.
2. Testez chacune par la phrase sans « et ».
3. Dans VOTRE projet todo : où vivrait la règle « titre ≤ 200 caractères » ? (une seule réponse correcte)

Résumé

• Manager/Utils = odeur de conception ; découper par intention.
• Forte cohésion + faible couplage = modules solos testables.
• La règle vit dans UNE classe, jamais dans trois.

UserService      dépend de UserRepository, EmailService
UserRepository   dépend du driver pg
EmailService     dépend du transporteur SMTP
PdfService       dépend d'une librairie PDF
StatsService     lit via UserRepository