Переписування Magento 2 класи проти плагінів


17

Magento 2 має концепцію плагінів / перехоплення / перехоплювачів, протилежних Magento 1.
Вони діють як раніше | після події для кожного публічного методу. Що приємно.
Ви також можете використовувати aroundплагін, щоб замінити функціональність методу.
Але Magento 2 все ще пропонує можливість переписати класи більш-менш M1 способом.
Я хотів би побачити кілька прикладів, коли переписування класів - це шлях, а не використання плагінів.
Я знаю, що це корисно, коли ви хочете змінити поведінку основного захищеного методу, але чи існують інші випадки, коли переписування рекомендується чи потрібно?


Відповіді:


19

Очевидною причиною використання переписати замість плагіна є те, коли вам потрібно перекрити приватний, захищений або остаточний методи .

Але також врахуйте наступні сценарії.

1-й сценарій (абсолютний порядок сортування):

Переписування може бути корисно, коли вам потрібно запустити код перед плагінами . Я знаю, що ви можете це зробити, встановивши плагін sortOrder, але ви не можете бути впевнені, що ваш код завжди буде першим, коли хтось (не ви) збирається встановити сторонні компоненти.

2-й сценарій (виключаємо код):

Якщо вам потрібно виключити або переписати лише фрагмент коду в методі, плагін може бути неоптимальним способом. Я знаю, що ви можете використовувати aroundплагін і уникати виклику proceed, але це може зламати інші плагіни у стеку.

3-й сценарій (стиль коду):

Ви повинні використовувати перезапис , коли вам потрібно переписати поведінку, плагіни повинні бути використані для зміни вихідного або виконання коду перед / після.

Плагін завжди повинен запускати оригінальний код, щоб уникнути зламу інших модулів.

Мій висновок:

Якщо ви можете розглянути основний метод як чорну скриньку з входом і одним виходом, і ви агресивно ставитеся до його внутрішніх механізмів, то плагін може бути найкращим варіантом.

Якщо вам потрібно змінити внутрішню поведінку , переписання може бути найкращим варіантом.


Перший сценарій трохи неточний (я думаю, це лише формулювання), оскільки плагін до або навколо нього працює (або може запускатися) перед фактичним кодом методу.
Девід Верхолен

Так, моє формулювання було невірним. Моя думка стосувалася відносного порядку сортування з фактичним методом.
Phoenix128_RiccardoT

7

Чудове запитання, я днями задав собі те саме, і ось що я придумав:

  • По-перше, плагіни не можна використовувати для кінцевих методів, заключних класів та класів, створених без введення залежності. Я вважаю, що це дуже конкретний випадок, але це один випадок, коли ви не можете використовувати плагіни
  • По-друге, потрібно пам’ятати про визначення плагіна. Він використовується для роботи на рівні методу, тоді як вподобання використовуються для роботи на рівні всього класу. Це не очевидно для всіх, тому добре пам’ятати про це.
  • Нарешті, і я вважаю, що це найважливіше, схоже плагіни можна використовувати лише для розширення поведінки будь-якого публічного методу в класі Magento . Таким чином, здається, що ви не можете використовувати плагіни із захищеними / приватними методами .

Джерело: Фундаментальний курс Magento U


2
Добре. Вагомі причини. Я не знаю, що сказати про другий момент. Якщо ви хочете підключити багато публічних методів з одного класу, я вважаю, що найбезпечнішим способом є створення єдиного класу, який виступає як плагін для всіх них. (моя думка). Я залишу це відкритим на 2-3 дні, щоб побачити, чи хтось придумає інші причини. Якщо ні .... галочка - ваша.
Маріус

@Marius Ви абсолютно праві: другий пункт. З якихось причин я подумав, що вам доведеться створити кілька файлів плагінів для кожного методу, який ви хочете підключити, але я думаю, що це роблять спостерігачі, а не плагіни. Це було б здорово, якщо більше людей відповідають, щоб дізнатися, чи є більше причин (не очевидних).
Рафаель у Digital Pianism

1
@marius як додаток: оскільки плагіни повинні бути доменними, я вважаю, що принаймні найкраща практика повинна визначати лише декілька плагінів в одному класі, якщо вони є реалізацією однієї і тієї ж функції. З перезаписом у вас немає цього варіанту, оскільки ви завжди змінюєте цілий клас. Тому я думаю, що це буде однією з причин хоча б спробувати уникнути переписувань
Девід Верхолен

@DavidVerholen. Я цілком погоджуюся. Але я просив причини використовувати переписування замість плагінів.
Маріус

так, я думаю, це може стати причиною використання плагінів, оскільки ви можете визначити особливості класів плагінів, тоді як перезапис можна зробити лише один раз
Девід Верхолен,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.