Réécriture des classes Magento 2 vs plugins


17

Magento 2 a le concept de plugins / interception / intercepteurs opposés à Magento 1.
Ceux-ci agissent comme un avant | après l'événement pour chaque méthode publique. Ce qui est bien.
Vous pouvez également utiliser le aroundplugin pour remplacer la fonctionnalité d'une méthode.
Mais Magento 2 offre toujours la possibilité de réécrire les classes plus ou moins à la manière M1.
J'aimerais voir quelques exemples où les classes de réécriture sont la voie à suivre au lieu d'utiliser des plugins.
Je sais que cela est utile lorsque vous souhaitez modifier le comportement d'une méthode protégée de base, mais existe-t-il d'autres cas où une réécriture est recommandée ou nécessaire?


Réponses:


19

La raison évidente d'utiliser une réécriture au lieu d'un plugin est lorsque vous devez remplacer une méthode privée, protégée ou finale .

Mais considérez également les scénarios suivants.

1er scénario (ordre de tri absolu):

Les réécritures peuvent être utiles lorsque vous avez besoin que votre code soit exécuté avant les plugins . Je sais que vous pouvez le faire en configurant le plugin sortOrder, mais vous ne pouvez pas être sûr que votre code sera toujours le premier lorsque quelqu'un (pas vous) va installer des composants tiers.

2ème scénario (exclure le code):

Si vous avez besoin d'exclure ou de réécrire juste un morceau de code dans une méthode, un plugin pourrait être un moyen sous-optimal. Je sais que vous pouvez utiliser un aroundplugin et éviter d'appeler le proceed, mais cela pourrait casser d'autres plugins dans la pile.

3e scénario (style de code):

Vous devez utiliser les réécritures lorsque vous devez réécrire un comportement, les plugins doivent être utilisés pour modifier la sortie ou exécuter le code avant / après.

Un plugin, devrait toujours exécuter le code d'origine pour éviter de casser d'autres modules.

Ma conclusion:

Si vous pouvez considérer une méthode principale comme une boîte noire avec une entrée et une sortie et que vous êtes agnostique quant à ses mécanismes internes, alors un plugin pourrait être la meilleure option.

Si vous devez modifier un comportement interne , une réécriture pourrait être la meilleure option.


Le premier scénario est légèrement inexact (je pense que ce n'est que le libellé) puisqu'un plugin avant ou arround s'exécute (ou peut s'exécuter) avant le code de la méthode réelle.
David Verholen

Oui, ma formulation n'était pas correcte. Mon point concernait l'ordre de tri relatif avec la méthode réelle.
Phoenix128_RiccardoT

7

Excellente question, je me suis posé la même chose l'autre jour et voici ce que j'ai trouvé:

  • Premièrement, les plugins ne peuvent pas être utilisés pour les méthodes finales, les classes finales et les classes créées sans injection de dépendance Je pense que c'est un cas très spécifique mais c'est un cas où vous ne pouvez pas utiliser de plugins
  • Deuxièmement, vous devez garder à l'esprit la définition d'un plugin. Il est utilisé pour travailler au niveau de la méthode tandis que les préférences sont utilisées pour travailler au niveau de la classe entière. Ce n'est pas évident pour tout le monde, il est donc bon de garder cela à l'esprit.
  • Enfin, et je pense que c'est le plus important, il semble que les plugins ne peuvent être utilisés que pour étendre le comportement de toute méthode publique au sein d'une classe Magento . Il semble donc que vous ne pouvez pas utiliser de plugins avec des méthodes protégées / privées .

Source: Magento U Fundamental Course


2
D'accord. De bonnes raisons. Je ne sais pas quoi dire du deuxième point cependant. Si vous souhaitez pluginiser un grand nombre de méthodes publiques de la même classe, je pense que le moyen le plus sûr est de créer une seule classe qui agit comme un plugin pour toutes. (mon avis). Je laisserai cela ouvert 2-3 jours pour voir si quelqu'un trouve d'autres raisons. Sinon .... la coche est la vôtre.
Marius

@Marius, vous avez absolument raison: deuxième point. Pour certaines raisons, je pensais que vous deviez créer plusieurs fichiers de plugins pour chaque méthode que vous vouliez pluginiser, mais je pense que c'est ce que font les observateurs, pas les plugins. Ce serait cool si plus de gens répondent pour voir s'il y a plus de raisons (non évidentes).
Raphael au Digital Pianism du

1
@marius en complément: comme les plugins doivent être spécifiques au domaine, je pense qu'il devrait au moins être préférable de ne définir que plusieurs plugins dans une classe, s'ils sont une implémentation de la même fonctionnalité. Avec une réécriture, vous n'avez pas cette option car vous changez toujours une classe entière. Je pense donc que ce serait une raison pour au moins d'essayer d'éviter les réécritures
David Verholen

@DavidVerholen. Je suis entièrement d'accord. Mais je demandais des raisons d'utiliser des réécritures au lieu de plugins.
Marius

oui, je pense que cela pourrait être une raison d'utiliser des plugins car vous pouvez définir des classes de plugins spécifiques à une fonctionnalité, tandis qu'une réécriture ne peut être effectuée qu'une seule fois
David Verholen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.