¿Qué clases son "interceptables / plugins" en Magento 2?

Fecha: 30 de mayo de 2015 (dada la naturaleza cambiante de Magento 2).

Magento 2 introdujo un concepto de complemento , implementado a través de un patrón interceptor .

Lo que no está claro en los documentos es: ¿qué clases y objetos en Magento son "interceptables"? Es decir, configura un complemento con XML similar al siguiente

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

pero no está claro qué clases son válidas como an ObservedType. Este artículo wiki más antiguo proporciona algunas pistas cuando dice

Tenga en cuenta que la función del complemento no se aplica a: - Clases creadas sin inyección de dependencia, es decir, creadas con operador nuevo directamente, - Métodos finales, - Clases finales

¿Hay algún objeto creado mediante inyección de dependencia disponible para ser interceptado? ¿La ObservedTypenecesidad de ser la sugerencia de tipo proporcionada en un __constructmétodo, o puede (¿debería?) Ser otra cosa?

Principalmente tratando de entender qué se puede y qué no se puede hacer con un interceptor Magento 2 antes de comenzar a usarlos.

Cada clase de un módulo de Magento es intercaptable.

Como se describe en el wiki actual, está limitado por los métodos y clases finales.

No validado, pero las clases de bibliotecas (directorio lib) no pueden (/ deberían) ser interceptadas.

Creo que la limitación de cómo se creó el objeto ya no es verdadera, al menos si el autocargador está configurado correctamente. Y no debería importar, ya que no se crean sobre la marcha, sino cuando se ejecuta el generador. (así que solo es cuestión de que el autocargador magento sea el primero)

Estamos trabajando en anotaciones "@api" para anotar los métodos recomendados que serán más estables en todas las versiones. Si le preocupa la capacidad de actualización, además de lo que puede tener un complemento definido, también debe considerar lo que debería tener un complemento definido. No recomendamos la intercepción de métodos que no sean @ api, pero a veces sabemos que puede ser la mejor opción. (Lo dejamos a discreción del desarrollador).

Oficialmente, puede interceptar métodos públicos que no son definitivos. Los métodos privados definitivamente no funcionarán. Desde la memoria, la intercepción actualmente funciona creando una clase descendiente que hereda la clase real (el marco de inyección de dependencia crea instancias de la clase generada cuando solicita una nueva instancia de la clase real). Por lo tanto, cualquier cosa que permita crear una subclase y anular el método original probablemente funcionará, pero se recomiendan los métodos públicos, lo que nos da flexibilidad para usar alguna otra implementación inteligente en el futuro (lo que nunca sucedería si fuera realista sin una buena razón) .

Sé que esto ya tiene una respuesta, pero es de hace 2 años. Tal vez algunas cosas cambiaron mientras tanto.

Aquí está lo que encontré hasta ahora.
De la documentación oficial y de profundizar en el proceso de intercepción.

Contestaré al revés.
Lo que NO PUEDE ser interceptado en Magento 2.
Del documento oficial

• Objetos que se instancian antes de que Magento \ Framework \ Interception se inicie (no estoy seguro de dónde está ese punto)
• Métodos finales
• Cualquier método de las clases finales (porque la clase interceptora generada tiene que extender la clase original)
• Cualquier clase que contenga al menos un método público final.
• Métodos no públicos (podría funcionar para métodos protegidos, pero esto no es "ético" ya que expondría los métodos no públicos al exterior de la clase)
• métodos estáticos
• __construir
• Tipos virtuales

De cavar

• métodos en clases que no se instancian a través del administrador de objetos. (Ejemplo \Magento\Framework\Phrase)
• implementación de clases \Magento\Framework\ObjectManager\NoninterceptableInterface. (Por ejemplo \Magento\Framework\App\Cache\Proxyy todos los otros proxies autogenerados)