Programmazione orientata agli oggetti in WordPress: analisi, parte 1
Quando ho deciso di offrire abbonamenti su questo sito, sapevo che la prima cosa che volevo affrontare era un’introduzione alla programmazione orientata agli oggetti.
È qualcosa che sembra essere interessante per la maggior parte delle persone che lavorano in WordPress, ma c’è un problema che allontana molte persone o genera scarsi risultati:
La programmazione orientata agli oggetti può complicarsi rapidamente. E questo diventa demotivante.
Ecco cosa intendo: supponiamo che tu sia uno sviluppatore di WordPress che inizia a ricercare la programmazione orientata agli oggetti. Inizia parlando di classi, costruttori e funzioni, e tutto sembra a posto.
Ma poi entra rapidamente in:
- metodi privati e protetti,
- eredità,
- polimorfismo,
- modelli di progettazione,
- iniezione di dipendenza,
- archivi,
- e così via.
Va a palle di neve, vero? E non è affatto così che deve essere, ma è difficile trovare un’introduzione adeguata a parte poche risorse disponibili.
Detto questo (e servendo da sfondo per dove sono diretto), ho voluto creare una serie di contenuti per coloro che:
- sono veramente interessati alla programmazione orientata agli oggetti,
- non sono sicuro da dove cominciare,
- vogliono accrescere le proprie capacità,
- vogliono iniziare da zero senza degenerare in materiale più complicato troppo rapidamente.
Ed è quello che comincio oggi e nella prima major seria prevista per i membri. Detto questo, iniziamo.
Nello specifico, iniziamo a parlare di programmazione, analisi, design orientata agli oggetti e perché dovrebbe iniziare da lì.
Programmazione orientata agli oggetti: analisi
Quando si tratta di scrivere codice, ci sono attualmente tre modi popolari per farlo:
Ogni volta che lavoriamo e leggiamo il codice di WordPress, leggerai una combinazione di codice procedurale e codice orientato agli oggetti.
Ci sono alcune ragioni per cui questo è il caso, ma non rientra nell’ambito della nostra discussione.
Questo perché WordPress è costruito con entrambi e perché alcuni aspetti dello sviluppo di WordPress possono essere scritti con codice procedurale, come plugin e temi, e altri richiedono uno sviluppo orientato agli oggetti come i widget.
Analisi e Progettazione
Molto spesso, la prima cosa che vogliamo fare, come sviluppatori (in erba o meno), è iniziare immediatamente a scrivere codice. Capisco anch’io. È divertente. Abbiamo un’idea, vogliamo darle vita, vogliamo iniziare a usarla e vogliamo mostrarla ad altre persone.
Tuttavia, ecco il problema nel farlo: spesso saltiamo direttamente nella scrittura del codice per cercare di fare in modo che il progetto faccia ciò che vogliamo che faccia.
Se questo è un progetto semplice (e intendo davvero semplice), allora non è un grosso problema. Onestamente, l’ho fatto (e GitHub ne è la prova). Ma quando si tratta del lavoro che svolgiamo in Pressware ; è una storia diversa.
Quando si tratta di progetti del genere, vogliamo fare un po’ di analisi e design prima di scrivere il codice.
Il che solleva la domanda, cos’è l’analisi e il design orientati agli oggetti?
Analisi
In breve, pensala in questo modo:
L’analisi è il processo di prendere l’idea che il cliente o che hai e scavare ciò che ha davvero bisogno di essere costruito.
Questo può aiutarti a determinare qual è il valore dell’applicazione e cosa non è necessario per la prima versione dell’applicazione. Mi piace etichettarli per quanto riguarda i "must-have" e quali sono i "bello da avere".
Una buona regola pratica è questa:
- i must-have sono le cose che sono fondamentali per l’applicazione e devono entrare nella prima iterazione del progetto,
- le cose belle da avere sono le cose che alla fine possiamo incorporarci
In definitiva, questo ci aiuta a lavorare verso una prima versione forte per il cliente. Forse un esempio è per WordPress:
- La prima versione di WordPress doveva avere un’API plug-in o doveva solo avere la possibilità per le persone di scrivere post e pubblicarli sul web?
Se stai costruendo una piattaforma per il blog, deve essere estensibile dalla prima versione? Questo non è altro che un esempio, ma hai un’idea.
Cosa rende l’analisi così difficile?
Penso che spesso abbia a che fare con i personaggi.
Ad esempio, noi, come programmatori, pensiamo che un progetto debba sempre fare ciò che vuole il cliente. La verità è che non è sempre così.
Voglio dire, alla fine potrebbe essere, ma la prima versione del progetto non deve necessariamente essere così.
Inoltre, uno dei principi di programmazione orientata agli oggetti è che non scriviamo molto codice duplicato. Ma può essere molto difficile da fare se non è stata eseguita un’analisi adeguata.
Infine, coloro che sono più esperti diranno che un buon software utilizzerà principi provati e veri, siano essi modelli di progettazione o meno, ma che è in grado di essere modificato facilmente nel tempo. Che, in un certo senso, cresce organicamente.
Allora cosa dobbiamo fare?
Nel prossimo articolo parlerò di tre cose che possiamo fare, come sviluppatori, per assicurarci che il software che stiamo costruendo per noi stessi o per gli altri ci porti nella giusta direzione.
Non dirò che è un proiettile d’argento perché non credo che esista, ma dirò che è un approccio piuttosto forte che ho trovato altri da usare e bene come me stesso e che porta a una buona direzione in termini di analisi orientata agli oggetti.
Questo alla fine ci porterà a progettare. Ma non ci siamo ancora.