Prototipazione rapida con WordPress: analisi concettuale
Nel post precedente, ho iniziato a seguire il processo per prendere l’idea di un plug-in che la prototipasse rapidamente in qualcosa che funzioni all’interno di WordPress. E sebbene funzioni, non segue necessariamente alcun principio orientato agli oggetti, né è in un luogo in cui possiamo facilmente continuare ad aggiungere funzionalità.
No, questo non è un argomento per spiegare perché l’orientamento agli oggetti è migliore. È il mio modo preferito di scrivere codice, quindi mi sto avvicinando in questo modo.
So che il codice di esempio che sto fornendo è semplice e so che è possibile creare un caso in cui qualcosa del genere può essere lasciato così com’è. Ma il punto è mostrare come prendere un concetto, prototiparlo e poi spostarlo in qualcosa che segua i principi orientati agli oggetti.
E, secondo la mia esperienza, è molto più difficile farlo con un esempio complesso fin dall’inizio. se perdi lettori dall’inizio, allora che speranza c’è per loro di capire cosa sta arrivando?
Detto questo, daremo un’occhiata al codice del post precedente e faremo un po’ di analisi concettuale su di esso per vedere cosa potrebbe funzionare bene all’interno di una classe e come potremmo iniziare a organizzarlo usando le classi, namespace e così via.
Analisi del concetto
Ogni volta che si tratta di programmazione, è così facile voler saltare immediatamente alla scrittura del codice e poi alla sua sottomissione fino a quando non fa qualcosa che vogliamo.
E una volta che funziona, sembra che abbiamo finito e possiamo passare al compito successivo. Ma per progetti più grandi, non è sempre così. In effetti, spesso è meglio fare un po’ di analisi concettuale dell’analisi orientata agli oggetti sul tuo progetto prima di andare avanti.
Il semplice passaggio alla programmazione non è sempre l’approccio migliore.
Un caso per l’analisi
Caso in questione: al momento della stesura di questo articolo, io e uno dei miei compagni di squadra stiamo discutendo se estendere una classe o scrivere una nuova classe per gestire le informazioni di geolocalizzazione per i dati estratti dall’API di Google Maps.
Posso alarlo e scrivere qualcosa che funzioni? Sicuro. Ma si integrerà bene con l’applicazione? Non senza analisi concettuale, pianificazione e coordinamento con il resto del sistema.
Ed è proprio questo lo scopo dell’analisi.
Analizzare il nostro lavoro
Quindi cosa significa questo per il plugin che abbiamo visto ieri? In questo momento, abbiamo quanto segue:
- una funzione responsabile della creazione di una meta box e della visualizzazione dei contenuti al suo interno,
- una funzione per interrogare il database e recuperare gli ultimi post più recenti,
- una funzione per visualizzare i risultati nella meta box
- una funzione per visualizzare un messaggio quando non ci sono risultati nella meta box
Inoltre, alcune di queste funzioni sono correlate agli hook che fanno parte dell’API di WordPress. Vale a dire, la funzione per creare il meta box è agganciata a WordPress e la sua funzione complementare per il rendering del display fanno tutte parte dello stesso componente.
Quindi abbiamo funzionalità per interrogare il database e abbiamo funzioni direttamente correlate alle viste.
Quindi, come potrebbe apparire se dovessimo diagrammarlo in varie classi e file che aiuterebbero a crearlo in un modo più orientato agli oggetti?
Nessuna soluzione unica
Non esiste un’unica soluzione e alcune soluzioni sono molto più avanzate di altre. Ma dal momento che sto cercando di trovare un equilibrio qui, mi avvicinerò a questo in un modo più semplice rispetto a fare troppo lavoro con l’astrazione, l’ereditarietà, le interfacce e tutto il resto.
Concentrandoci su ciò che abbiamo
Per ora, concentriamoci sulle singole classi e sulle responsabilità che possono ricoprire. Per esempio:
- Penso che avremo bisogno di una classe che rappresenti la meta box. Questo dovrebbe essere responsabile della creazione della meta box.
- Avremo anche bisogno di una classe responsabile della visualizzazione del contenuto della meta box. Potresti pensare che includere una funzione nella classe per la meta box funzioni bene. Lo fa; tuttavia, se si vuole pensare che ogni classe abbia un’unica responsabilità, allora possiamo creare una classe specifica per il display e specificamente per il meta box, quindi iniettare il display nel meta box durante l’istanza. Ne parleremo più avanti.
A questo punto, il nostro diagramma potrebbe assomigliare a questo:
Abbattere la meta box.
Successivamente, dobbiamo considerare l’altra funzionalità. Vale a dire, la funzionalità per visualizzare i risultati nella meta box e la funzionalità per visualizzare i risultati quando non ce ne sono.
Per visualizzare qualsiasi cosa nella meta box, dobbiamo avere un modo per interrogare il database per recuperare i risultati. Da lì, dobbiamo quindi essere in grado di avere un modo per determinare se ci sono risultati, se non ci sono e quindi iniettare quei risultati nella vista.
Date queste informazioni, sembra che abbiamo bisogno di una classe per interrogare il database e quindi abbiamo bisogno di una classe per ampliare un messaggio nella visualizzazione del meta box.
Forse un modo per organizzare le classi sarebbe questo:
Interrogazione del database e preparazione dei messaggi.
La versione finale del diagramma potrebbe essere un po’ angusta, ma alla fine stiamo guardando qualcosa del genere:
L’organizzazione finale per le nostre classi.
Ai fini della spiegazione:
- Il post retriever chiede al database gli ultimi tre post più recenti.
- Il post messenger determinerà quale messaggio iniettare nel display.
- Il display visualizzerà il messaggio che è stato impostato.
- La meta box renderà la sua visualizzazione al browser web.
Quindi abbiamo essenzialmente preso alcune funzioni che erano collegate a WordPress e le abbiamo suddivise in componenti che possono comunicare tra loro, ognuna delle quali è relativamente facile da lavorare e non fa più di un singolo lavoro.
Convertirlo in codice
Ora che abbiamo un’idea su come convertire il concetto precedente in codice, vedremo come farlo nei prossimi due articoli.
Nota che il modo in cui scegli di implementare il tuo codice o progettare le tue classi potrebbe essere leggermente diverso da quello che ho sopra e potresti avere suggerimenti su come organizzare meglio ciò che è sopra. Se è così, lascia un commento.
Nel prossimo post, cercheremo di convertirlo in codice funzionale e, successivamente, cercheremo di organizzarlo in spazi dei nomi appropriati e una corretta organizzazione dei file.
Messaggi di serie
- Prototipazione rapida con WordPress: dal concetto al plug-in
- Prototipazione rapida con WordPress: analisi concettuale
- Prototipazione rapida: da prototipazione a codice, parte 1
- Prototipazione rapida: dal prototipo al codice, parte 2
- Prototipazione rapida: introduzione del caricamento automatico

