Quando si sviluppa un plug-in, le funzioni devono essere raggruppate in una classe per evitare conflitti nello spazio dei nomi?
Sì, ma questo è solo uno degli argomenti minori. In realtà questa non è la natura "vera" di una classe in OOAD .
L'uso delle classi crea costi generali per le prestazioni di PHP?
No, in particolare. La cattiva progettazione e / o il cattivo codice scritto o l'ottimizzazione pre-matura creano molti più problemi di prestazioni rispetto alle caratteristiche del linguaggio reale.
Se si verifica un hit delle prestazioni, i nomi delle funzioni dovrebbero essere pre-fissati?
Come scritto, non vi è alcun impatto sulle prestazioni. Il codice scritto errato sarà più un successo prestazionale che un buon codice scritto che ha più righe di codice ma non ti costringe a fare cose cattive.
Linea di fondo:
Puoi utilizzare diversamente le classi per i plugin. Puoi semplicemente usarli per avere una sorta di spazio dei nomi e usarli "solo" per funzioni globali. La forma più diretta di ciò sono le funzioni di classe statica, il seguente esempio di codice mostra sia le prime funzioni globali che le funzioni globali di classe statica:
/* global function */
function myplug_hook()
{
}
add_filter('the_hook', 'myplug_hook');
/* global static function */
class myplug
{
public static function hook()
{
}
}
add_filter('the_hook', 'myplug::hook');
Questo è solo un piccolo esempio che mostra che è necessario digitare di più per il singolo hook. Inoltre mostra come funziona lo spazio dei nomi: è possibile sostituire più facilmente il nome della singola classe per rinominare tutte le funzioni statiche e quindi cercare e sostituire myplug::che potrebbero essere più difficili a myplug_causa di falsi positivi. Ma alla fine non c'è molta differenza.
Il punto chiave è: le funzioni di classe statiche Doc non sono molto altro che funzioni globali Doc .
E anche questo esempio mostra: lo spazio dei nomi va bene, ma con worpdress lo spazio dei nomi si interrompe con l'uso degli hook: la funzione di callback è codificata, quindi il vantaggio nello spazio dei nomi usando la classe (un posto per il nome di base, il nome della classe) non aiuto quando intervieni il tuo codice con wordpress per i nomi hook.
Il vero vantaggio inizia con l'utilizzo di istanze di classe effettive e funzioni non statiche. Ciò ha il vantaggio di poter iniziare a utilizzare i principi OO e di semplificare il codice. Le funzioni di classe statiche sono più un problema che una soluzione.
Quindi è più di un semplice zucchero sintattico.
Il punto chiave è: fare qualcosa che ti aiuti a scrivere il codice che puoi gestire e gestire facilmente. Non sopravvalutare le prestazioni, è un errore comune. Ancora più importante è scrivere codice che sia facile da leggere e da capire, che fa proprio quello di cui hai bisogno. Forse questa domanda e risposta è utile per un'immagine più ampia in questo contesto: Guida Metabox personalizzata multipla .
Un approccio comune che ho anche con plug-in più piccoli è l'utilizzo di una funzione di supporto statico per istanziare il plug-in e il resto risiede all'interno dell'istanza del plug-in. Questo aiuta a incapsulare la logica principale del plug-in e trae vantaggio dalla spaziatura dei nomi con gli hook e che i membri privati possono essere riutilizzati tra hook che non è possibile con le funzioni globali standard. Il seguente esempio di codice mostra il modello:
<?php
/** Plugin Headers ... */
return MyPlugin::bootstrap();
class MyPlugin
{
/** @var MyPlugin */
static $instance;
static public function bootstrap() {
if (NULL === self::$instance) {
self::$instance = new __CLASS__;
}
return self::$instance;
}
# ...
}
Questo è un modello comune che uso per il file del plugin di base. La classe plugin da un lato rappresenta il plugin per wordpress e dall'altro consente di iniziare a utilizzare paradigmi orientati agli oggetti per il proprio codice che può anche essere completamente orientato agli oggetti (ma non è necessario). È una specie di controller, che si interfaccia con l'intera API wordpress come richiesta (e).
Come mostra l'esempio, verrà creata un'istanza del plugin. Ciò ti consente di utilizzare i beni comuni conosciuti come un Costruttore Documenti ( __construct) per inizializzare il plugin effettivo:
# ...
class MyPlugin
{
# ...
public function __construct()
{
add_filter('the_hook', array($this, 'hook'));
}
public function hook()
{
}
# ...
}
Al momento della registrazione dell'hook, questo oggetto plug-in beneficia già del suo design: hai smesso di codificare la funzione hook reale rispetto al nome classe del plug-in concreto . Ciò è possibile a causa dell'associazione della classe all'istanza dell'oggetto per il callback. Sembra complicato, solo dicendo: $this è il plugin. Può essere utilizzato nei callback hook, confronta i metodi di registrazione della classe come callback hook .
Questo modello consente un'interfaccia più semplice con wordpress: l'iniezione è ridotta ai nomi degli hook e ai dati che forniscono. Puoi quindi iniziare a implementare direttamente in questa classe di plug-in o a riformattare la tua implementazione contro di essa, in modo da mettere solo il codice nella classe di plug-in che è il minimo indispensabile per definire l'interfaccia dei plug-in contro wordpress, ma tieni la logica generale da parte di worpdress. È qui che inizia il divertimento e molto probabilmente quello che ogni autore di plugin vuole raggiungere nel lungo periodo.
Quindi non programmare con worpdress ma contro di esso. Poiché worpdress è abbastanza flessibile, non esiste un'interfaccia comune o facile da descrivere per la programmazione. Una classe di plugin di base può assumere questo ruolo, offrendoti una maggiore flessibilità per il tuo codice, il che porterà a un codice più semplice e a prestazioni migliori.
Quindi non c'è solo un vantaggio per la spaziatura dei nomi. Il miglior suggerimento che posso dare è: mettiti alla prova. Non c'è molto che perderai, solo nuove cose da scoprire.
Molto probabilmente noterai differenze dopo aver superato alcuni altri importanti aggiornamenti di wordpress mantenendo compatibile il tuo plug-in.
Avvertenza : se il plug-in si integra direttamente con wordpress per completare il lavoro, l'utilizzo di una o due funzioni pubbliche potrebbe adattarsi meglio a te. Prendi lo strumento giusto per il lavoro.