Quelles classes sont «interceptables / pluginables» dans Magento 2

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

Magento 2 a introduit un concept de plugin , implémenté via un modèle d'intercepteur .

Ce qui n'est pas clair dans la documentation 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. Cet ancien article wiki fournit des indices quand il dit

Veuillez noter que la fonction de plugin ne s'applique pas aux - Classes créées sans injection de dépendance, c'est-à-dire créées directement avec l'opérateur new, - Méthodes finales, - Classes finales

Est tout objet créé par l' injection de dépendance disponibles à intercepter? Est-ce que le ObservedTypebesoin doit être le conseil de type fourni dans la __constructméthode a, ou peut-il (devrait-il?) Être autre chose?

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

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 (/ devraient) pas être interceptées.

La limitation de la façon dont l'objet a été créé n'est plus vraie, je pense, du moins si l'autochargeur 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é. (donc ce n'est qu'une question de, l'autochargeur magento devrait être le premier)

Nous travaillons sur des annotations "@api" pour annoter les méthodes recommandées qui seront plus stables d'une version à l'autre. Si vous vous inquiétez de la mise à niveau, en plus de ce qui peut avoir un plugin défini, vous devriez également considérer ce qui 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 des méthodes publiques qui ne sont pas définitives. Les méthodes privées ne fonctionneront certainement pas. De la 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, ce qui nous donne la flexibilité d'utiliser une autre implémentation intelligente à l'avenir (ce qui ne serait jamais réaliste sans bonne raison) .

Je sais que cela a déjà une réponse, mais elle 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.
De la documentation officielle et de creuser dans le processus d'interception.

Je répondrai dans l'autre sens.
Ce qui NE PEUT PAS être intercepté dans Magento 2.
D'après le document officiel

• Objets instanciés avant le démarrage de Magento \ Framework \ Interception (vous ne savez pas où se trouve ce point)
• Méthodes finales
• Toute méthode des classes finales (car la classe d'intercepteur générée doit étendre la classe d'origine)
• Toute classe qui contient 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

De creuser autour

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