Riscrivere le classi Magento 2 vs Plugin


17

Magento 2 ha il concetto di Plugin / Intercettazione / Intercettori contrapposto a Magento 1.
Questi si comportano come un evento precedente | per ogni metodo pubblico. Che bello.
Puoi anche usare il aroundplugin per sostituire la funzionalità di un metodo.
Ma Magento 2 offre ancora la possibilità di riscrivere le classi più o meno nel modo M1.
Vorrei vedere alcuni esempi in cui le classi di riscrittura sono la strada da percorrere invece di usare i plugin.
So che questo è utile quando si desidera modificare il comportamento di un metodo protetto core, ma ci sono altri casi in cui è raccomandata o necessaria una riscrittura?


Risposte:


19

Il motivo ovvio per utilizzare una riscrittura anziché un plug-in è quando è necessario sovrascrivere un metodo privato, protetto o finale .

Ma considera anche i seguenti scenari.

1 ° scenario (ordinamento assoluto):

Le riscritture possono essere utili quando è necessario eseguire il codice prima dei plug-in . So che puoi farlo impostando il plugin sortOrder, ma non puoi essere sicuro che il tuo codice sarà sempre il primo quando qualcuno (non tu) installerà componenti di terze parti.

2 ° scenario (escludi codice):

Se è necessario escludere o riscrivere solo una parte di codice in un metodo, un plug-in potrebbe essere un modo non ottimale. So che puoi usare un aroundplugin ed evitare di chiamare il proceed, ma questo potrebbe spezzare altri plugin nello stack.

3 ° scenario (stile codice):

Dovresti usare la riscrittura quando devi riscrivere un comportamento, i plugin dovrebbero essere usati per modificare l'output o eseguire il codice prima / dopo.

Un plugin, dovrebbe sempre eseguire il codice originale per evitare la rottura di altri moduli.

La mia conclusione:

Se puoi considerare un metodo di base come una scatola nera con un input e un output e sei agnostico riguardo ai suoi meccanismi interni, allora un plug-in potrebbe essere l'opzione migliore.

Se è necessario modificare un comportamento interno , una riscrittura potrebbe essere l'opzione migliore.


Il primo scenario è leggermente impreciso (penso che sia solo il testo) poiché un plugin prima o intorno viene eseguito (o può essere eseguito) prima del codice del metodo effettivo.
David Verholen,

Sì, la mia formulazione non era corretta. Il mio punto riguardava il relativo ordinamento con il metodo effettivo.
Phoenix128_RiccardoT

7

Ottima domanda, mi sono posto la stessa cosa l'altro giorno ed ecco cosa mi è venuto in mente:

  • Innanzitutto, i plug-in non possono essere utilizzati per metodi finali, classi finali e classi create senza iniezione di dipendenza, credo sia un caso molto specifico, ma è un caso in cui non è possibile utilizzare plug-in
  • In secondo luogo, è necessario tenere presente la definizione di un plug-in. Viene utilizzato per lavorare a livello di metodo, mentre le preferenze vengono utilizzate per l'intero livello di classe. Non è ovvio per tutti, quindi è bene tenerlo a mente.
  • Infine, e credo che sia il più importante, sembra che i plugin possano essere usati solo per estendere il comportamento di qualsiasi metodo pubblico all'interno di una classe Magento . Quindi sembra che non puoi usare plugin con metodi protetti / privati .

Fonte: Corso base Magento U


2
Ok. Buoni motivi Non so cosa dire del secondo punto però. Se vuoi plug-in molti metodi pubblici della stessa classe, penso che il modo più sicuro sia quello di creare una singola classe che funga da plug-in per tutti. (la mia opinione). Lascerò questo aperto 2-3 giorni per vedere se qualcuno si presenta con altri motivi. Altrimenti .... il segno di spunta è tuo.
Marius

@Marius hai assolutamente ragione riguardo al secondo punto. Per alcuni motivi ho pensato che dovevi creare diversi file di plugin per ogni metodo che volevi rendere plug-in, ma penso che sia quello che fanno gli osservatori, non i plugin. Sarebbe bello se più persone rispondano per vedere se ci sono più ragioni (non ovvio).
Raffaello al Pianismo digitale,

1
@marius come aggiunta: poiché i plug-in dovrebbero essere specifici del dominio, penso che dovrebbe essere almeno una buona pratica definire solo più plug-in in una classe, se si tratta di un'implementazione della stessa funzionalità. Con una riscrittura, non hai questa opzione poiché cambi sempre un'intera classe. Quindi penso che sarebbe un motivo per almeno cercare di evitare le riscritture
David Verholen,

@DavidVerholen. Sono totalmente d'accordo. Ma stavo chiedendo motivi per usare la riscrittura invece dei plugin.
Marius

sì, penso che questo potrebbe essere un motivo per usare i plugin poiché puoi definire classi di plugin specifiche per funzionalità, mentre una riscrittura può essere fatta solo una volta
David Verholen,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.