Les plugins dans Magento 2

Lors du weekend OpenGento 2024, j’ai fait une petite présentation sur les plugins dont j’avais déjà un peu parlé dans ce blog de leur utilisation dans l’article ne plus étendre dans Magento 2. Lors d’un récent audit, je me suis rendu compte que une habitude déjà constaté il y a quelques années s’était répandue. Le plugin around devenait l’outil privilégié pour une surcharge. Mais quelle ne fut pas ma surprise de voir que des plugins avaient été utilisé sur les méthodes insert et fetchAssoc de l’adaptateur de base de données pas comme surcharge mais pour vérifier s’il fallait ou non un papier cadeau.

Mon but a été alors de me mettre en prêche pour décrire ce que doit être un plugin. Pour cela, je me suis basé sur une pub des années 90 de la marque sharp avec Eric Cantona comme personnage principal. Sharp peut vouloir dire précis, pointu ou affuté selon les cas. Ce sont les adjectifs qui définissent pour moi le mieux ce que doit être un plugin.

Qu’est-ce qu’un plugin ?

Un plugin est un morceau de code qu’on va choisir d’exécuter avant, après ou autour de n’importe quelle méthode publique d’une classe. Magento va créer une classe intermédiaire qui se chargera des interceptions. Cette classe se trouvera dans le sous-dossier correspondant au module dans le dossier generated. La publicité de la méthode est nécessaire et d’autres limitations existent. La méthode doit pouvoir être interceptée, c’est à dire que la classe où elle se trouve est instanciée après Magento et n’étend pas NonInterceptableInterface. La méthode ne doit pas être finale ou statique. Il existe encore quelques limitations qu’il est possible de découvrir dans la documentation de Magento 2 sur les plugins.

Définitions de sharp

Précis

Le plugin (intercepteur) doit être précis. Cela veut dire qu’il doit s’exécuter le moins de fois possibles. Comme pour l’observer, plus il s’exécute, plus la demande en ressource va augmenter. Pour cela, il doit respecter le principe de responsabilité unique (Single Responsability Principle) dont vous avez déjà entendu parlé si vous êtes des lecteurs assidus.

Pointu

Un plugin doit être le plus léger possible. Les dépendances injectées doivent être limitées au strict nécessaire, de préférence en lecture seule et utiliser des proxies si les classes en question sont vraiment lourdes et que leur utilisation n’est pas certaine.

Il ne doit pas remplacer une configuration, un service, un modèle de vue, un router, un observer ou une classe virtuelle.

Affuté

La méthode d’interception around doit rester limitée à un certain nombre de cas exceptionnels. Si la méthode modifie la sortie, c’est un plugin after et si elle modifie un paramètre en entrée, c’est un before. L’exécution de l’intercepteur ne doit pas faire grand chose de plus que modifier des entrées et sorties. Si c’est le cas, il est préférable d’utiliser une surcharge de la classe. Contrairement à ce qui est parfois dit, les plugins ne facilitent pas la maintenance du code.