Jakie klasy są „Przechwytywalne / Plugin” w Magento 2

Data: 30 maja 2015 r. (Biorąc pod uwagę zmieniający się charakter Magento 2).

Magento 2 wprowadziło koncepcję wtyczki , zaimplementowaną za pomocą wzorca przechwytującego .

Co nie jest jasne z dokumentów - które klasy i obiekty w Magento są „przechwytywalne”? Oznacza to, że konfigurujesz wtyczkę z XML, która wygląda następująco

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

ale nie jest jasne, które klasy są ważne jako ObservedType. Ten starszy artykuł wiki zawiera pewne wskazówki, kiedy to mówi

Należy pamiętać, że funkcja wtyczki nie ma zastosowania do - klas utworzonych bez wstrzykiwania zależności, to znaczy, utworzonych przy użyciu nowego operatora bezpośrednio, - metod końcowych, - klas końcowych

Czy można przechwycić dowolny obiekt utworzony za pomocą wstrzykiwania zależności? Czy ObservedTypepotrzebna jest wskazówka typu podana w __constructmetodzie, czy może (czy powinna?) Być czymś innym?

Głównie próbuję obejść to, co można, a czego nie można zrobić za pomocą przechwytywacza Magento 2, zanim zacznę ich używać.

Każda klasa modułu Magento jest kompatybilna.

Jak opisano na bieżącej wiki, jest on ograniczony przez ostateczne metody i klasy

Nie sprawdzono poprawności, ale klasy bibliotek (katalog lib) są (/ powinny) nie zostać przechwycone.

Myślę, że ograniczenie tworzenia obiektu nie jest już prawdą, przynajmniej jeśli autoloader jest poprawnie skonfigurowany. I nie powinno mieć znaczenia, ponieważ nie są tworzone w locie, ale kiedy generator zostanie wykonany. (więc to tylko kwestia, autoloader Magento powinien być pierwszy)

Pracujemy nad adnotacjami „@api”, aby opisywać zalecane metody, które będą bardziej stabilne we wszystkich wydaniach. Jeśli martwisz się o możliwość aktualizacji, oprócz tego, co może mieć zdefiniowaną wtyczkę, powinieneś również rozważyć, co powinno mieć zdefiniowaną wtyczkę. Nie zalecamy przechwytywania metod innych niż API, ale czasami wiemy, że może to być najlepsza opcja. (Pozostawiamy to twórcy).

Oficjalnie możesz przechwytywać metody publiczne, które nie są ostateczne. Prywatne metody zdecydowanie nie zadziałają. Przechwytywanie z pamięci obecnie działa, tworząc klasę potomną, która dziedziczy klasę rzeczywistą (struktura wstrzykiwania zależności tworzy instancje wygenerowanej klasy, gdy poprosisz o nową instancję klasy rzeczywistej). Wszystko, co pozwoli na utworzenie podklasy i zastąpienie oryginalnej metody, prawdopodobnie będzie działać, ale zalecane są metody publiczne, co daje nam elastyczność w korzystaniu z innej sprytnej implementacji w przyszłości (co nigdy nie byłoby realistyczne bez uzasadnionego powodu) .

Wiem, że to już odpowiedź, ale pochodzi ona sprzed 2 lat. Może w międzyczasie niektóre rzeczy się zmieniły.

Oto, co znalazłem do tej pory.
Z oficjalnej dokumentacji i od zagłębienia się w proces przechwytywania.

Odpowiem na odwrót.
Czego NIE MOŻNA przechwycić w Magento 2.
Z oficjalnego dokumentu

• Obiekty, które są tworzone przed utworzeniem Magento \ Framework \ Interception, są ładowane (nie wiadomo, gdzie jest ten punkt)
• Ostateczne metody
• Każda metoda z klas końcowych (ponieważ wygenerowana klasa przechwytująca musi rozszerzyć klasę oryginalną)
• Każda klasa, która zawiera co najmniej jedną ostateczną metodę publiczną
• Metody niepubliczne (może działać dla metod chronionych, ale nie jest to „etyczne”, ponieważ wystawiałoby metody niepubliczne na zewnątrz klasy)
• metody statyczne
• __skonstruować
• Typy wirtualne

Od przekopywania się

• metody w klasach, które nie są tworzone przez menedżera obiektów. (Przykład \Magento\Framework\Phrase)
• realizacja zajęć \Magento\Framework\ObjectManager\NoninterceptableInterface. (Na przykład \Magento\Framework\App\Cache\Proxyi wszystkie inne automatycznie generowane proxy)