Widget WordPress: rileva la programmazione orientata agli oggetti

Last updated Dic 14, 2022

Contenuto

Qual è il problema, esattamente?

Come rilevare la programmazione orientata agli oggetti

Una parola sul codice errato

Torna alla programmazione orientata agli oggetti

Eredità

Astrazione

Prossimo

Se non hai letto il primo post di questa serie, te lo consiglio, poiché stiamo iniziando a scrivere codice orientato agli oggetti per WordPress attraverso l’uso dell’API Widgets.

La serie catturerà alcune cose:

mostrarti lo scheletro di base di un widget e perché è orientato agli oggetti,
discuti quali cose dovresti essere in grado di notare e perché
prima aggiorna il Widget Boilerplate direttamente su questo sito e poi invialo a GitHub,
costruire un widget utilizzando l’API con il boilerplate come base per il nostro lavoro.

Ma prima di farlo, voglio assicurarmi che tutti coloro che leggono questo articolo siano coinvolti nei principi fondamentali della programmazione orientata agli oggetti e abbiano tutto il necessario per costruire una soluzione orientata agli oggetti per WordPress.

A tal fine, ti consiglio quanto segue:

Se hai letto tutto questo contenuto, fantastico. Sarai ben preparato per questo post e per i prossimi post. In caso contrario, potrebbero esserci dei buchi nel resto di ciò che stai per leggere, ma il succo del post dovrebbe essere abbastanza chiaro.

Qual è il problema, esattamente?

Ecco il punto: la scorsa settimana ho condiviso un po’ di codice insieme ad alcune informazioni sull’API dei widget. Lo rivisiterò un po’ di più in questo post prima di entrare nella parte più intensiva del codice per due motivi:

Voglio che tutti coloro che leggono questo articolo siano sulla stessa pagina per quanto riguarda la scrittura di codice orientato agli oggetti (almeno, in questo contesto),
Riconosco che le persone provengono da background diversi e voglio assicurarmi che siamo tutti sulla stessa pagina il più possibile prima di procedere.

Se hai esperienza con la scrittura di codice orientato agli oggetti, specialmente in una capacità avanzata, questo potrebbe sembrarti più semplice; in caso contrario, spero che questo ti fornisca tutto ciò di cui hai bisogno per rilevare le pratiche orientate agli oggetti non solo riguardo a questa API ma anche durante la lettura del codice degli altri.

Come rilevare la programmazione orientata agli oggetti

Forse una prima domanda naturale è perché dobbiamo essere in grado di rilevare, leggere o comprendere la programmazione orientata agli oggetti prima di scriverla effettivamente?

Una parola sul codice errato

La risposta breve è questa:

Non è necessario, ma è utile. Se sei in grado di leggere la programmazione orientata agli oggetti, avrai un vantaggio nell’trarre vantaggio da ciò che offre come paradigma perché svilupperai sulle strategie e sul lavoro svolto da altri in altri progetti.

Ciò non significa che non leggeremo il codice errato, ma faremo il possibile per identificare il codice errato, identificare le aree problematiche e quindi fare il possibile per evitare di incorporarlo nel nostro lavoro.

Per ora, però, diamo un’occhiata all’API Widgets per vedere cosa possiamo fare per rilevare la programmazione orientata agli oggetti.

Torna alla programmazione orientata agli oggetti

Nel post precedente, ho delineato due cose che indicano che l’API è orientata agli oggetti (almeno in una certa misura):

l’uso della parola chiave extends ,
funzioni che dobbiamo implementare.

Il motivo per cui voglio rivisitare questo argomento è che identifica due cose chiave che fanno parte dei principi fondamentali orientati agli oggetti: l’ ereditarietà e l’implementazione delle funzioni (che spesso fa parte delle classi astratte ).

Una nota prima di guardare quanto sopra:

Quando guardi il sorgente della classe WP_Widget, noterai che non ci sono metodi astratti. Ma alcune delle funzioni che dobbiamo implementare, che menzionerò più avanti in questo post, sono i primi candidati per i metodi astratti. E parlerò anche del perché.

Separiamo gli argomenti sopra in due sezioni separate: Ereditarietà e Astrazioni.

Eredità

Ho trattato l’ereditarietà è la profondità relativa nel post precedente, quindi non mi soffermerò sul punto qui. Offrirò alcune parole, ma sono molto più interessato a discutere dell’astrazione, cosa che farò tra un momento.

Prima di entrare troppo in questo, però, fare riferimento al seguente codice:

<?php
class AcmeWidget extends WP_Widget 
{ 
    public function __construct() 
    {
    }

    public function widget($args, $instance) 
    {
    }

    public function form($instance)
    {
    }

    public function update($newInstance, $oldInstance)
    {
    }
}

Ma prima, possiamo riconoscere che qualsiasi classe che implementa l’API Widgets deve utilizzare l’ereditarietà semplicemente a causa della parola chiave extends.

Ciò significa che c’è un livello di funzionalità che erediteremo (o che otterremo gratuitamente) e c’è un livello di funzionalità che dobbiamo implementare da soli.

Dal manuale PHP :

Ad esempio, quando si estende una classe, la sottoclasse eredita tutti i metodi pubblici e protetti dalla classe padre. A meno che una classe non sostituisca questi metodi, manterranno la loro funzionalità originale.

Quando erediti la funzionalità da una classe, tuttavia, potresti scoprire che è importante chiamare rigorosamente il costruttore del genitore (nella nostra funzione __construct ).

Ma questo solleva quello che ritengo essere uno dei problemi più importanti con l’ereditarietà in PHP (e l’intero motivo per cui volevo includere questa sezione): dobbiamo chiamare esplicitamente il costruttore genitore?

Anche secondo il manuale:

I costruttori padre non vengono chiamati in modo implicito se la classe figlio definisce un costruttore. Per eseguire un costruttore padre, è richiesta una chiamata a parent::__construct() all’interno del costruttore figlio. Se il figlio non definisce un costruttore, può essere ereditato dalla classe genitore proprio come un normale metodo di classe (se non è stato dichiarato privato).

Ma possiamo semplificare questo. Forse questo è più facile da ricordare:

Se la nostra classe usa l’ereditarietà ma non definisce un costruttore, viene chiamato il costruttore genitore.
Se la nostra classe usa l’ereditarietà ma definisce un costruttore, il costrutto genitore deve essere chiamato esplicitamente.

O forse anche più semplicemente:

Se la nostra classe non definisce un costruttore, il codice verrà impostato automaticamente sul costruttore dei genitori.

Ha senso? In breve, se definiamo le nostre proprietà, l’inizializzazione e il codice in un costruttore, la prima riga del costruttore della nostra classe dovrebbe essere una chiamata al costruttore genitore.

Astrazione

Per essere assolutamente chiari, il codice sorgente della classe WP_Widget non include metodi astratti. Parte di questo ha a che fare con il modo in cui è costruita la classe, parte di questo ha a che fare con la compatibilità con le versioni precedenti e le funzionalità di PHP5.

Ciò non significa che non possiamo identificare quali funzioni potrebbero essere contrassegnate come abstract, però. In effetti, penso che sia un caso su quali classi dovrebbero essere rese astratte. Ma prima, definiamo le funzioni astratte.

Dal manuale :

Quando si eredita da una classe astratta, tutti i metodi contrassegnati come astratti nella dichiarazione di classe del genitore devono essere definiti dal figlio; inoltre, tali modalità devono essere definite con la stessa (o meno ristretta) visibilità.

Osservando la fonte del nostro widget:

<?php
class AcmeWidget extends WP_Widget 
{ 
    public function __construct() 
    {
    }

    public function widget($args, $instance) 
    {
    }

    public function form($instance)
    {
    }

    public function update($newInstance, $oldInstance)
    {
    }
}

Penso che sia giusto dire che la funzione form potrebbe essere contrassegnata come astratta perché è unica per la nostra implementazione. Un altro modo di pensare alle funzioni astratte dal punto di vista della programmazione è chiedersi: quali funzioni richiederanno funzionalità uniche?

E in questo caso, la funzione del modulo è proprio quella perché ogni widget sarà diverso in modo univoco rispetto a ciò che rende. La funzione widget può anche essere contrassegnata come astratta perché restituisce il contenuto del widget. Questo contenuto è, naturalmente, basato sulla funzionalità che abbiamo implementato nella nostra implementazione.

Inoltre, il codice sorgente della stessa classe WP_Widget dice:

la funzione WP_Widget::widget() deve essere sovrascritta in una sottoclasse.’

Questo è precisamente il tipo di funzione che dovrebbe essere contrassegnata come astratta. Perché PHP genererà un errore se una funzione è contrassegnata come astratta e non implementata. Non avevamo bisogno di chiamate di funzione die o qualcosa del genere.

Le altre funzioni, tuttavia, non dovranno necessariamente essere contrassegnate come astratte ed ecco perché:

__construct chiamerà il costruttore del genitore, al livello più elementare, e questo è necessario per inizializzare la classe base. Non dimenticare, però; possiamo aggiungere le nostre proprietà a questo metodo che sono uniche per la nostra classe.
update utilizza la funzionalità nella classe padre per la serializzazione delle informazioni.

Quindi, ci rimangono due funzioni che potrebbero essere contrassegnate come astratte in un’iterazione più moderna della classe.

Prossimo

A questo punto, dovremmo essere tutti sulla stessa pagina per quanto riguarda il codice orientato agli oggetti. Almeno per quanto possiamo ottenere attraverso una serie di post sul blog.

A partire dal prossimo post, torneremo a scrivere il codice.

Cioè, rivisiteremo il WordPress Widget Boilerplate e lo refactoring nel suo stato attuale per adottare standard PHP più moderni.

Condividerò le modifiche che sto apportando, le giustificazioni sul perché, e poi parlerò anche del tipo di widget che costruiremo in base al boilerplate (e possiamo farlo).

Fonte di registrazione: tommcfarlin.com