Parte 4 – WordPress e programmazione orientata agli oggetti: un esempio di WordPress – Design

A questo punto, abbiamo requisiti chiaramente definiti come sono stati descritti nella Parte 3 di questa serie (controlla qui se te lo sei perso).

Ora è il momento di iniziare a pensare al design del nostro nuovo e migliorato plugin!

Vorremmo ricordarti che questo passaggio potrebbe richiedere molto tempo quando lo proverai sui tuoi progetti. Probabilmente non otterrai tutto bene neanche la prima volta. È probabile che ti venga in mente un progetto, inizi a implementarlo e poi ti rendi conto che devi tornare indietro e ripensare al tuo approccio.

Ne vale assolutamente la pena, quindi prenditi tutto il tempo necessario per fare tutto bene. Un progetto ben strutturato renderà più facile mantenerlo ed estenderlo e persino riutilizzarne il codice in altri progetti, quindi a lungo termine è un buon uso del tempo.

Subito dopo, ci concentreremo su alcune parti chiave del plugin e discuteremo di come siamo arrivati ​​al nostro design.

Analisi della pagina delle impostazioni

Diamo un'occhiata più da vicino alla pagina di amministrazione del plugin.

Noterai che c'è un titolo ("Limita impostazioni tentativi di accesso"), diverse sezioni contenenti alcuni campi e un pulsante "Modifica opzioni" nella parte inferiore della pagina.

Ogni sezione è composta da un titolo, come "Statistiche", e da alcuni campi.

Ogni campo ha un titolo a sinistra e il resto del suo contenuto a destra. Ci sono campi di testo, pulsanti di opzione e caselle di controllo e, alcuni di essi, come "Blocchi totali", visualizzano solo informazioni e non possono essere modificati direttamente dall'utente amministratore.

Alcuni campi includono anche una descrizione, come il campo "Connessione al sito", ma non tutti.

Tenendo presente quanto sopra, dobbiamo scomporlo in pezzi concettuali che in seguito diventeranno classi.

L'API delle impostazioni di WordPress ci consente di registrare pagine delle impostazioni, sezioni all'interno di tali pagine e campi all'interno delle sezioni:

Pagine → Sezioni → Campi

Abbiamo pensato, perché non aggiungere un ulteriore “livello”, gli Elements, per rendere il nostro plugin più facile da estendere in futuro.

Pagine → Sezioni → Campi → Elementi

Quindi, Pagine e Sezioni sono ciò che abbiamo già spiegato sopra e Campi conterranno Elementi di qualsiasi tipo di contenuto sul lato destro.

Prendendo in considerazione tutti questi diversi tipi di elementi, siamo andati con una classe Element e diverse classi, estendendola, per le caselle di controllo, i pulsanti di opzione, i numeri ecc. che renderanno un output diverso.

Potrebbe anche essere necessario aggiungere più pagine e sezioni in futuro. Quindi è probabile che dovremmo estendere queste pagine di amministrazione e classi di sezione.

Lo stesso vale per i campi. Le classi per "Blocchi totali", "Blocchi attivi" ecc. estenderanno la stessa classe (principale).

Ecco un'immagine semplificata che dimostra queste relazioni:

Naturalmente, non tutti i "componenti" sono inclusi nel diagramma.

Una struttura come questa rende il plugin più facile da estendere; siamo in grado di aggiungere facilmente un campo, un elemento o una sezione in caso di necessità. Saremo in grado di aggiungere facilmente più componenti (campi, elementi o sezioni) creando nuove classi figlie, senza dover modificare quelle esistenti.

Pensare e astrarre

Ora è un ottimo momento per iniziare a pensare a cosa fanno i vari componenti del nostro plugin. Durante la fase di progettazione, non dobbiamo entrare nei dettagli su come funziona qualcosa.

Ad esempio, considera tutti gli elementi, le tabelle, le statistiche e praticamente qualsiasi altra cosa che verrà mostrata all'utente. Potrebbero essere componenti separati senza nulla in comune, ma alla fine renderanno tutti alcuni output. Pertanto, alcune funzionalità saranno comuni per i componenti che altrimenti non sarebbero completamente correlati. Naturalmente, questo si estende anche al resto dei nostri componenti.

Nell'immagine sopra, vediamo come un'interfaccia dell'interfaccia utente viene implementata da più classi.

Prestare attenzione al fatto che l'interfaccia dell'interfaccia utente è implementata dalle classi Statistics, Lockout Logs, Table ed Element, denominate classi padre . Non è necessario che le classi Radio/Number/Checkbox Element implementino direttamente l'interfaccia, poiché ereditano tutte le interfacce dalla loro classe padre. Tuttavia, una classe figlia potrebbe sovrascrivere un metodo della sua classe padre.

Poiché sappiamo che il nostro plugin si occuperà delle impostazioni, possiamo tranquillamente presumere che leggeremo e scriveremo i loro valori. Cioè, essere in grado di ottenere , impostare e rimuovere le opzioni.

Tutte queste azioni verranno raggruppate in una classe. Probabilmente memorizzeremo le nostre opzioni nel database di WordPress o qualcosa del genere. Per ora, non dobbiamo preoccuparci di come o dove memorizzeremo i nostri dati.

Possiamo mantenere l' astrazione delle opzioni get/set/remove nella nostra mente, semplificando le cose concettualmente e continuare a progettare il nostro plugin.

File plug-in principale

Qui, forniremo alcune informazioni sul plug-in a WordPress attraverso il commento dell'intestazione ed eseguiremo alcune inizializzazioni. Organizzeremo il nostro codice, racchiudendo tutto in una piccola classe.

A seconda di come le classi del nostro plugin lavoreranno insieme, la classe principale dovrà istanziarne la maggior parte. Per quanto ne sappiamo, questo includerà classi relative a opzioni, pagine di amministrazione, tentativi e blocchi.

Classi potenziali

Ci siamo presi del tempo per cercare di capire di quali classi avremo bisogno e abbiamo finito con un elenco come segue:

• Riprova
• Blocchi
• Biscotti
• Messaggio di errore
• Notifiche di posta elettronica
• Avvisi dell'amministratore
• Bottoni
• Registri di blocco
• Blocchi attivi/totali
• indirizzo IP

Tieni presente che non esiste un unico modo "corretto" per strutturare il tuo plug-in. Come per la maggior parte delle cose nello sviluppo del software, ci sono modi multipli, ugualmente validi, per risolvere un problema.

Nella sezione "Generale", ad esempio, le relazioni tra le nostre classi sarebbero così:

La sezione "Statistiche" sarà simile a questa:

Infine, i "Registri di blocco" saranno molto simili a "Statistiche":

Conclusione

Finora abbiamo definito i nostri requisiti e pensato a un design per il nostro nuovo plug-in migliorato. Abbiamo spiegato come abbiamo creato la nostra struttura e fornito anche alcuni semplici diagrammi che mostrano come le nostre classi saranno correlate tra loro.

Fare clic qui per leggere la parte 5 della nostra serie di programmazione orientata agli oggetti

Guarda anche

• WordPress e programmazione orientata agli oggetti: una panoramica
• Parte 2 – WordPress e programmazione orientata agli oggetti: un esempio del mondo reale
• Parte 3 – WordPress e programmazione orientata agli oggetti: Α Esempio di WordPress – Definizione dell'ambito