Due modi per sviluppare plugin WordPress programmazione funzionale

Questa parte due di una serie esamina due diversi stili di programmazione (talvolta chiamati paradigmi di programmazione) che è possibile utilizzare durante la scrittura di plug-in di WordPress. Nella prima parte Tom McFarlin ha coperto la programmazione orientata agli oggetti. In questa parte vedremo la programmazione funzionale.

Poiché il livello di esperienza dei lettori varia, parleremo di programmazione ad alto livello, quindi se sei un principiante, non dovresti avere problemi a seguirlo. Se, tuttavia, sei uno sviluppatore più esperto, puoi trovare più informazioni utili più avanti nell'articolo.


Che cos'è la programmazione funzionale?

La programmazione funzionale è probabilmente lo stile con cui si è più familiari - e quasi universalmente - lo stile utilizzato nei vari siti Web di frammenti di codice WordPress che circolano su Internet. Per questo motivo a volte può essere vista come una programmazione di "entry level": lo stile utilizzato dai principianti fino a quando non hanno imparato a padroneggiare la programmazione orientata agli oggetti. Questo è incredibilmente fuorviante, perché mentre la programmazione funzionale è molto più semplice, non è di per sé inferiore.

La programmazione funzionale enfatizza la valutazione delle funzioni ed evita la nozione di stati o oggetti rispetto alla programmazione orientata agli oggetti che incoraggia a pensare al codice come ad agire sugli oggetti, usando metodi per cambiare quegli oggetti o interagire con essi. Diamo un'occhiata ad un esempio molto semplice che confronta i due stili:

 // Funzione del metodo funzionale add_two ($ n) return $ n +2;  $ a = 2; $ b = add_two ($ a); // $ b = 4; // Classe del metodo orientato agli oggetti Number var $ value = 0; function __construct ($ a) $ this-> value = $ a;  function add_two () $ this-> value = $ this-> value +2;  $ a = new Number (2); echo $ a-> valore; // Stampa 2 $ a-> add_two (); echo $ a-> valore; // Stampa 4

Questo esempio molto semplice illustra la differenza fondamentale nello stile dei due paradigmi: la programmazione funzionale si concentra sul passare argomenti e ricevere valori dalle funzioni. Non ci sono "oggetti" su cui si agisce, solo parametri e valori di ritorno. Viceversa, l'approccio orientato agli oggetti assegna a un oggetto varie proprietà (nel nostro caso un "valore") e i metodi agiscono su tali proprietà.


Funzioni: le nozioni di base

La definizione delle funzioni è molto semplice:

 function add ($ number, $ number2 = 1) // Esegue il codice che agisce sulle variabili passate $ sum = $ number + $ number2; // Facoltativo, se necessario è possibile restituire un valore return $ sum; 

Una volta dichiarata la funzione, può essere utilizzata ovunque nel plug-in, in altre parole ha portata globale.

 $ a = 4; $ b = 7; echo add ($ a, $ b); // Stampa 11
Le funzioni devono avere nomi univoci. La redizione di una funzione genera un errore. Poiché il tuo codice verrà eseguito insieme ad altri plug-in, temi e WordPress, non dovrai mai utilizzare nomi generici. Invece dovresti anteporre i nomi delle tue funzioni a qualcosa di unico (come il nome del tuo plug-in).

Potresti aver notato che nella definizione di Inserisci, il secondo argomento è uguale a 1. Questo imposta un valore predefinito per $ numero2 (in questo caso, 1), e così facendo rende l'argomento opzionale. Se l'argomento non viene fornito, il valore viene considerato come il valore predefinito:

 echo add (4); // Stampa 5 echo add (4, 1); // Stampa 5

D'altra parte, non viene fornito alcun valore predefinito per il primo valore, quindi omettere quell'argomento genererà un errore

 echo add (); // Genera un errore in quanto il numero $ non è definito

Puoi anche avere un numero variabile di argomenti. All'interno della funzione che possiamo usare func_num_args () per ottenere il numero di argomenti ricevuti, mentre func_get_arg () ti consente di accedere a una determinata variabile passata, indicizzata da 0.

 function sum () // Ottieni il numero di argomenti dati a sum () $ number_args = func_num_args (); $ somma = 0; se (! $ numero_arg) restituisce $ somma; per ($ i = 0; $ i < $number_args; $i++ )  $sum += func_get_arg( $i );  return $sum;  echo sum( 1, 2, 3, 4 ); //Prints 10 echo sum( 1, 2 ); //Prints 3 echo sum(); //Prints 0

Quanto sopra può essere usato anche nei metodi oggetto. Infine, dichiarando una variabile come "globale", è possibile accedere alla variabile dall'interno di una funzione.

 $ a = 'Ciao'; $ b = 'Mondo'; function hello_world () // Questo è necessario per accedere a $ ae $ b // dichiarato al di fuori dell'ambito della funzione. globale $ a, $ b; $ b = $ a. ". $ b; hello_world (); echo $ b; // Stampa 'Hello World'
L'uso dei globals è generalmente scoraggiato. In particolare, poiché due plug-in che utilizzano lo stesso nome per una variabile globale possono causare l'interruzione di uno o entrambi i plug-in. Se devi utilizzare una variabile globale, di nuovo assicurati che sia univoca eseguendo il prefisso con il nome del plug-in.

Perché utilizzare la programmazione funzionale?

Decidere quale stile di programmazione usare dipende dal giudizio - e sì - dalle preferenze personali. Non è più giusto o sbagliato usare la programmazione funzionale rispetto ad oggetti, ma più spesso c'è uno stile che è più adatto per quello che stai cercando di ottenere.

A volte la programmazione orientata agli oggetti semplicemente non è necessaria, e solo oltre complica le cose, o introduce codice superfluo. Un esempio potrebbero essere le varie funzioni di "utilità" fornite da WordPress. Queste sono funzioni generiche che servono per eseguire uno scopo particolare. Per esempio wp_trim_words ($ text, $ num_words) taglia semplicemente la stringa data ad una certa dimensione (in parole). Non aggiungerebbe nulla da definire wp_trim_words () invece come un metodo appartenente ad un oggetto, e risulterebbe in un codice più brutto. Con la programmazione funzionale prende una linea.

Un vantaggio della programmazione funzionale, in particolare per i principianti, è la sua semplicità. Non devi preoccuparti delle funzioni statiche, private o protette: sono tutte globali. Neanche esiste la nozione di variabili statiche. Al livello base, la tua funzione restituisce un risultato derivato da ciò che hai dato. Per esempio, get_the_title (7) restituirà il titolo per il post con ID 7.

Un altro vantaggio della programmazione funzionale è che le funzioni sono accessibili a livello globale. Con i programmi orientati agli oggetti, per agire su un oggetto specifico, è necessario passare attorno a quell'oggetto. Questo a volte può essere complicato. Per illustrare questo, prendiamo un esempio dalla prima parte:

 class DemoPlugin public function __construct () add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts'));  public function register_plugin_scripts () // Registra script di plugin $ demo_plugin = new DemoPlugin ();

Quando WordPress memorizza il register_plugin_scripts () metodo in modo che possa essere chiamato quando il wp_enqueue_scripts l'azione viene attivata facendo così riferimento non solo al metodo, ma anche all'oggetto $ demo_plugin. Questo perché viene considerato lo stesso metodo per diverse istanze di un oggetto diverso metodi - cioè, $ Demo_plugin-> register_plugin_scripts () e $ Copy_of_demo_plugin-> register_plugin_scripts () non sono la stessa cosa Questo può sembrare strano, ma i metodi possono comportarsi in modo diverso per istanze diverse della stessa classe, quindi dobbiamo fare riferimento sia al metodo che all'istanza.

Ma perché questo importa? Rende molto difficile per un plug-in o un tema di terze parti sganciare quel metodo, poiché per farlo dovrebbero chiamare:

 remove_action ('wp_enqueue_scripts', array ($ demo_plugin, 'register_plugin_scripts'));

Ma in generale non avranno accesso al $ demo_plugin variabile. (Nota: se il metodo è dichiarato statico, puoi aggirare questo).


Programmazione orientata agli oggetti e funzionale in WordPress

Ovviamente la programmazione orientata agli oggetti ha i suoi vantaggi, come discusso nella prima parte. Come Tom ha anche menzionato, è inevitabile quando si utilizza l'API widget di WordPress. Un altro esempio comune è WP_Query (). Qui un approccio orientato agli oggetti è chiaramente il migliore: hai un oggetto (in questo caso una query), che ha varie proprietà (cioè criteri di ricerca, informazioni di paginazione, risultati corrispondenti) e vuoi agire su quella query (analizzarlo, generare e disinfettare l'SQL corrispondente e restituire i risultati).

WP_Query () dimostra come una potente programmazione orientata agli oggetti può essere utilizzata correttamente. Dopo aver avviato la query:

 $ the_query = new WP_Query (array (...));

Non solo è possibile accedere ai risultati, ma anche altre informazioni quali i valori di impaginazione: quante pagine di risultati ci sono, quale pagina viene visualizzata, il numero totale di risultati e il "tipo" di query, ad es.. $ The_query-> is_search (), $ The_query-> is_single () ecc. C'è anche l'intera infrastruttura del "ciclo";

 if ($ the_query-> have_posts ()) echo '
    '; while ($ the_query-> have_posts ()): $ the_query-> the_post (); // The Loop echo '
  • '. get_the_title ($ the_post-> ID). '
  • '; ENDWHILE; eco '
'; wp_reset_postdata ();

Che nasconde tutta la giocoleria interna di risultati e globalmente dietro una API umana.

E allora? get_posts ()? Questo serve solo come involucro per WP_Query (), e restituisce semplicemente una serie di messaggi che corrispondono alla query. In quanto tale, non si ottengono le "campane e fischietti" di WP_Query (), ma è leggermente più efficiente. Quindi se dovresti usare get_posts () o WP_Query () dipende dal tuo caso d'uso (ad esempio, se richiedi l'impaginazione o meno), ma dipende anche dalle preferenze personali.

 $ results = get_posts (array (...)); se ($ risultati) echo '
    '; foreach ($ risultati come $ the_post) echo '
  • '. get_the_title ($ the_post-> ID). '
  • '; eco '
';

Sommario

Speriamo che questi due articoli abbiano contribuito a evidenziare i vantaggi e gli svantaggi di questi stili di programmazione. Il punto di partenza è che qui non c'è giusto e sbagliato, e ogni programmatore avrà le sue preferenze personali. Ma alcuni contesti si prestano più facilmente ad un certo stile di programmazione - e come tale dovresti aspettarti che il tuo plug-in contenga una combinazione di entrambi.