O que são classes "interceptáveis ​​/ plugins" no Magento 2

Data: 30 de maio de 2015 (dada a natureza mutável do Magento 2).

O Magento 2 introduziu um conceito de plug-in , implementado através de um padrão interceptador .

O que não está claro nos documentos é: quais classes e objetos no Magento são "interceptáveis"? Ou seja, você configura um plug-in com XML parecido com o seguinte

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

mas não está claro quais classes são válidas como ObservedType. Este artigo antigo da wiki fornece algumas dicas quando diz

Observe que o recurso de plug-in não se aplica a - Classes criadas sem injeção de dependência, ou seja, criadas com o operador new diretamente, -Final methods, -Final classes

Existe algum objeto criado por injeção de dependência disponível para interceptação? A ObservedTypenecessidade de ser a dica de tipo fornecida no __constructmétodo a ou pode (deveria?) Ser outra coisa?

Principalmente tentando entender o que pode e o que não pode ser feito com um interceptador Magento 2 antes de começar a usá-los.

Toda classe de um módulo Magento é intercaptable.

Conforme descrito no wiki atual, ele é limitado pelos métodos e classes finais

Não validado, mas Classes de bibliotecas (diretório lib) não são (/ deveriam) permitidas a interceptação.

A limitação de como o objeto foi criado não é mais verdadeira, eu acho, pelo menos se o carregador automático estiver configurado corretamente. E não deve importar, pois eles não são criados em tempo real, mas quando o gerador foi executado. (portanto, é apenas uma questão de, o carregador automático magento deve ser o primeiro)

Estamos trabalhando nas anotações "@api" para anotar os métodos recomendados que serão mais estáveis ​​nas versões. Se você se preocupa com a capacidade de atualização, além do que pode ter um plug-in definido, você também deve considerar o que deve ter um plug-in definido. Não recomendamos a interceptação de métodos que não sejam @ api, mas às vezes sabemos que essa pode ser a melhor opção. Deixamos isso a critério do desenvolvedor.

Oficialmente, você pode interceptar métodos públicos que não são finais. Métodos privados definitivamente não funcionam. Na memória, atualmente a interceptação funciona criando uma classe descendente que herda a classe real (a estrutura de injeção de dependência cria instâncias da classe gerada quando você solicita uma nova instância da classe real). Portanto, qualquer coisa que permita a criação de uma subclasse e o método original substituído provavelmente funcionará, mas métodos públicos são recomendados, dando-nos flexibilidade para usar outra implementação inteligente no futuro (o que nunca seria realista sem uma boa razão) .

Eu sei que isso já tem uma resposta, mas é de 2 anos atrás. Talvez algumas coisas tenham mudado nesse meio tempo.

Aqui está o que eu encontrei até agora.
A partir da documentação oficial e da escavação no processo de interceptação.

Eu responderei o contrário.
O que NÃO PODE ser interceptado no Magento 2.
A partir do documento oficial

• Objetos que são instanciados antes da inicialização do Magento \ Framework \ Interception (não sei onde está esse ponto)
• Métodos finais
• Qualquer método das classes finais (porque a classe interceptora gerada precisa estender a classe original)
• Qualquer classe que contenha pelo menos um método público final
• Métodos não públicos (poderia funcionar para métodos protegidos, mas isso não é "ético", pois exporia métodos não públicos ao exterior da classe)
• métodos estáticos
• __construir
• Tipos virtuais

De cavar

• métodos em classes que não são instanciadas por meio do gerenciador de objetos. (Exemplo \Magento\Framework\Phrase)
• implementação de classes \Magento\Framework\ObjectManager\NoninterceptableInterface. (Por exemplo, \Magento\Framework\App\Cache\Proxye todos os outros proxies gerados automaticamente)