Comment adapter un comportement spécifique sans casser les autres usages.

Plutôt que de toucher directement au service d’origine, j’ai utilisé la décoration Symfony. Concrètement, j’ai fait ce choix :

App\Service\Crud\CustomUserCrudService:
  decorates: 'Zama\UserBundle\Service\Crud\UserCrudService'
  decoration_priority: 10
  arguments:
    $dispatcher: '@event_dispatcher'
    $factory: '@form.factory'
    $entityManager: '@doctrine.orm.entity_manager'
    $authorizationChecker: '@security.authorization_checker'

Pourquoi j’ai fait ce choix

Le service d’origine est utilisé un peu partout. Le modifier directement aurait été risqué :

  • effets de bord imprévisibles
  • impact sur des parties que je ne maîtrise pas
  • complexité pour les autres équipes

La décoration m’a permis de :

  • garder le service d’origine intact
  • injecter uniquement mon besoin métier
  • limiter l’impact à mon contexte

Sur le papier, c’est exactement ce qu’on attend d’une architecture propre.

Les points positifs:

Clairement, il y a des avantages :

  • Pas de surcharge 
    Je ne touche pas au bundle, donc pas de problème lors des mises à jour.
  • Impact maîtrisé
    Je sais précisément où mon comportement s’applique.
  • Respect du principe Open/Closed
    J’étends sans modifier.

Dans un contexte de CMS partagé, c’est souvent le bon compromis.

Les points négatifs:

Mais aussi des désavantages:

  • Lisibilité
    La décoration a un gros défaut, elle cache de la complexité. Sans documentations, il faut penser à regarder le service.yaml
  • Effet empilement
    Le vrai risque, c’est quand on commence à multiplier les décorateurs.
  • Couplage implicite
    Si le service change, mon décorateur peut casser sans que ce soit évident.

Mon retour

Dans ce cas précis, je referais le même choix.
Le besoin était local, et je ne voulais pas imposer une modification globale.

Par contre, je garde en tête que :

  • ce n’est pas une solution “gratuite”
  • ça ajoute de la dette côté compréhension
  • ça doit rester une exception, pas une norme

Recommandations

Avec un peu de recul, voilà comment j’essaie d’encadrer l’usage :

  • Toujours documenter pourquoi le service est décoré
    Sinon, personne ne comprendra dans 6 mois.
  • Limiter à un seul décorateur par service
    Si ça commence à s’empiler → problème d’architecture.
  • Garder le décorateur simple
    Une responsabilité claire, pas de logique métier lourde.
  • Remettre en question si le besoin revient souvent
    Dans ce cas, il vaut mieux revoir le design global (events, stratégie, etc.)

Conclusion

La décoration Symfony est un outil très pratique quand on veut intervenir proprement sur un service existant.

Mais c’est aussi un outil qui peut vite rendre un projet difficile à lire si on en abuse.