Quelles classes sont « interceptables/pluginables » dans Magento 2

Question

Date:30 mai 2015 (compte tenu de la nature changeante de Magento 2).

Magento 2 introduit un concept de plugin, mis en œuvre via un modèle d'intercepteur.

Ce qui n'est pas clair dans la documentation, c'est : quelles classes et quels objets dans Magento sont « interceptables » ?Autrement dit, vous configurez un plugin avec XML qui ressemble à ce qui suit

<config>
    <type name="{ObservedType}">
        <plugin name="{pluginName}" type="{PluginClassName}" sortOrder="1" disabled="true"/>
    </type>
</config>

mais il n'est pas clair quelles classes sont valides en tant que ObservedType.Ce article wiki plus ancien fournit quelques indices quand il dit

Veuillez noter que la fonctionnalité du plugin ne s'applique pas - classes créées sans injection de dépendance, c'est-à-dire créée avec l'opérateur nouveau directement,-méthodes fininales,-classes finales

Est n'importe lequel objet créé via injection de dépendances disponible pour être intercepté ?Est-ce que le ObservedType doit être l'indice de type fourni dans le a __construct méthode, ou cela peut-il (devrait-il ?) être autre chose ?

J'essaie principalement de comprendre ce qui peut et ne peut pas être fait avec un intercepteur Magento 2 avant de commencer à les utiliser.

Answer 1

Chaque classe d'un module Magento est intercaptable.

Comme décrit sur le wiki actuel, il est limité par les méthodes et classes finales.

Non validé, mais les classes de bibliothèques (répertoire lib) ne sont (/ ne devraient pas) être autorisées à être interceptées.

La limitation de la création de l'objet n'est plus vraie, je pense, du moins si le chargeur automatique est correctement configuré.Et cela ne devrait pas avoir d'importance car ils ne sont pas créés à la volée, mais lorsque le générateur a été exécuté.(ce n'est donc qu'une question de savoir si le chargeur automatique magento devrait être le premier)

Answer 2

Nous travaillons sur des annotations "@api" pour annoter recommandé méthodes qui seront plus stables à travers les versions.Si vous vous souciez de l'évolutivité, en plus de quoi peut avoir un plugin défini, vous devez également considérer ce que devrait avoir un plugin défini.Nous ne recommandons pas l'interception de méthodes non @api, mais nous savons parfois que cela peut être la meilleure option.(Nous laissons cela à la discrétion du développeur.)

Officiellement, vous pouvez intercepter les méthodes publiques qui ne sont pas définitives.Les méthodes privées ne fonctionneront certainement pas.De mémoire, l'interception fonctionne actuellement en créant une classe descendante qui hérite de la classe réelle (le framework d'injection de dépendances crée des instances de la classe générée lorsque vous demandez une nouvelle instance de la classe réelle).Donc, tout ce qui permettra de créer une sous-classe et de remplacer la méthode d'origine fonctionnera probablement, mais les méthodes publiques sont recommandées, nous donnant la flexibilité d'utiliser une autre implémentation intelligente à l'avenir (ce qui n'arriverait jamais étant réaliste sans bonne raison) .

Answer 3

Je sais que cela a déjà une réponse, mais cela date d'il y a 2 ans.Peut-être que certaines choses ont changé entre-temps.

Voici ce que j'ai trouvé jusqu'à présent.
Du documentation officielle et de fouiller dans le processus d'interception.

Je répondrai dans l'autre sens.
Quoi NE PEUT PAS être intercepté dans Magento 2.
Extrait du document officiel

• Objets instanciés avant le démarrage de Magento\Framework\Interception (je ne sais pas où se trouve ce point)
• Méthodes finales
• Toute méthode des classes finales (car la classe intercepteur générée doit étendre la classe d'origine)
• Toute classe contenant au moins une méthode publique finale
• Méthodes non publiques (cela pourrait fonctionner pour les méthodes protégées mais ce n'est pas "éthique" car cela exposerait les méthodes non publiques à l'extérieur de la classe)
• méthodes statiques
• __construction
• Types virtuels

En fouillant partout

• méthodes dans les classes qui ne sont pas instanciées via le gestionnaire d'objets.(Exemple \Magento\Framework\Phrase)
• classes implémentant \Magento\Framework\ObjectManager\NoninterceptableInterface.(Par exemple \Magento\Framework\App\Cache\Proxy et tous les autres proxys générés automatiquement)