Di recente ho esaminato il processo di utilizzo di un costruttore di classe per impedire a un plug-in di funzionare se non viene caricata una dipendenza prevista.
Sebbene non consideri questa particolare strategia un problema per una dipendenza una tantum o in determinate situazioni, ci sono modi in cui questo può portare a odori di codice.
Ci impedisce anche di utilizzare una funzionalità nativa di Core chiamata sottoazioni di WordPress:
https://twitter.com/JJJ/status/822265137935646720
Ma prima di esaminare le sottoazioni, voglio assicurarmi di essere chiaro sui problemi che l’uso dell’approccio condizionale (rispetto alle sottoazioni) può riprodursi con gli odori del codice.
Sottoazioni di WordPress
Ci sono molti modi in cui gli odori del codice possono essere spiegati, ma il mio modo preferito viene da Martin Fowler :
…gli odori sono determinate strutture nel codice che indicano la violazione dei principi fondamentali di progettazione e incidono negativamente sulla qualità del progetto.
C’è un’altra fantastica pagina sugli odori del codice su Source Making che consiglio di leggere se ne hai la possibilità.
E il modo in cui i condizionali possono portare a odori di codice è semplice: ha il potenziale per disseminare il tuo codice con un enorme insieme di istruzioni che includono molti controlli class_exists.
E questo è un problema.
Ogni volta che introduci un’altra dipendenza nel tuo codice, finisci per aggiungere un altro controllo condizionale per vedere se una classe è presente nell’applicazione WordPress.
Credo che vada bene farlo con una singola dipendenza – forse anche due dipendenze – e se stai lavorando "abbastanza in alto" nella tua architettura, ma questo non è come gestirlo correttamente con molte dipendenze né a un livello inferiore in il tuo plugin
È qui che entrano in gioco le sottoazioni di WordPress. Puoi vedere un elenco di sottoazioni nel tweet tramite John sopra.
C’è anche una definizione ufficiale delle sotto-azioni nel bbPress Codex :
Queste azioni interne possono essere considerate "azioni secondarie" e consentono di aggiungere o riordinare le azioni di WordPress secondo necessità per i plugin che dipendono da bbPress.
E puoi vederne un esempio in questo file.
Certo, questa definizione è specifica per bbPress, ma ciò non significa che non sia applicabile a ciò che facciamo in WordPress.
Caso in questione: se hai mai usato do_action per definire un’azione personalizzata, o hai sfruttato un hook fornito da qualcun altro al di fuori del core di WordPress, allora hai familiarità con la strategia di implementazione di un’azione secondaria.
In altre parole, le sottoazioni di WordPress sono semplicemente azioni che possiamo utilizzare per modificare l’ordine in cui il nostro plug-in dipende da un altro plug-in.
Il modo in cui viene implementato può variare nel contesto del tuo lavoro, ma il modo più popolare e "corretto" di WordPress per farlo è probabilmente sfruttare l’ argomento prioritario per quando il tuo plug-in viene caricato.
Cioè, prendi la priorità della dipendenza e assicurati che sia prima di quando il tuo plugin è attivato.
Esistono metodi alternativi che possono essere utilizzati, come modificare il comportamento dei plug-in ogni volta che vengono attivati o meno, ma questo esula dallo scopo di questo particolare post e potrebbe alterare negativamente l’esperienza dell’utente (di WordPress in generale, non meno).
Indipendentemente da ciò, il punto è che quando si tratta di utilizzare le sottoazioni di WordPress, la programmazione orientata agli oggetti e la gestione delle dipendenze di terze parti, assicurati che le decisioni che stai prendendo non danneggino il design del tuo codice.
Se ha senso verificare l’esistenza di una classe, ok, ma se ha più senso attendere che una serie di classi o plug-in sia stata caricata prima della tua, allora le sottoazioni di WordPress probabilmente hanno più senso.