I primi due pilastri di OOP

Quando si tratta di parlare di programmazione orientata agli oggetti (o OOP), è probabile che tu senta parlare dei tre pilastri della programmazione orientata agli oggetti o dei quattro pilastri della programmazione orientata agli oggetti.

A seconda del tuo background, potresti averne già sentito parlare, sapere cosa sono e non hai davvero bisogno di immergerti troppo. Ma se non l’hai fatto, credo che capirli sia fondamentale per la programmazione orientata agli oggetti.

Abbiamo coperto l’intera fase di analisi della programmazione orientata agli oggetti:

1. Analisi, parte 1
2. Analisi, parte 2
3. Comprendere le aspettative dei clienti
4. Dichiarazione di lavoro
5. Termini e Condizioni

Detto questo, entriamo nelle discussioni di progettazione e implementazione. Dopotutto, questo è ciò a cui molte persone vogliono saltare comunque, vero?

Prima di scrivere qualsiasi codice, vorrei fare due post sui quattro punti della programmazione orientata agli oggetti (perché sono uno di quelli che aderisce all’idea che ce ne siano quattro).

Due pilastri dell’OOP

Ancora una volta, comprenderli è la chiave per comprendere le basi della programmazione orientata agli oggetti. Senza di loro, sarà difficile navigare nel resto di ciò che verrà discusso nei post futuri.

Detto questo, parliamo di ciascuno di essi. Tratteremo i primi due in questo post e gli ultimi due nel prossimo post.

1 Astrazione

In generale, questa è la chiave per scrivere codice orientato agli oggetti. Con ciò, intendo tutto ciò che è contenuto all’interno di una classe. Astraiamo l’idea di qualcosa in una classe. In molti libri vedremo cose come Animali o Macchine rappresentate come classi.

Funziona, in teoria, ma in pratica, non stiamo programmando animali né stiamo programmando automobili (anche se immagino che a questo punto della storia, potresti sostenere che lo siamo, ma sto divagando perché sai cosa intendo).

Invece, astrarremo le idee nelle loro classi. E qui c’è un’idea chiave:

Una classe dovrebbe rappresentare un sostantivo.

Cioè, non dovresti avere una classe che rappresenti qualcosa come "Running". Invece, potresti avere qualcosa che funziona e, quindi, le corse sarebbero un metodo. E questa è la ripartizione generale di come funziona l’astrazione:

1. La cosa che deve essere rappresentata è la classe,
2. Le cose che fa la cosa sono i suoi metodi,
3. E il modo in cui descrivi la cosa di solito può essere fatto tramite i suoi attributi o proprietà.

Questo non significa che non abbiamo funzioni o metodi che ne modifichino le proprietà, ma i tre punti precedenti sono buone regole pratiche. Quindi, quando stai progettando una classe, puoi chiedere cose come:

• Sto scrivendo qualcosa?
• Sto scrivendo qualcosa da fare?
• O sto scrivendo qualcosa che descriva qualcosa?

Perché se stai scrivendo un’azione, è probabile che sia fatta da qualcosa (perché le cose agiscono, loro fanno cose). E se stai descrivendo qualcosa, probabilmente si riferisce a qualcosa (quando è stata l’ultima volta che non hai descritto nulla?)

Ha senso?

2 Incapsulamento

Quindi, se stiamo scrivendo classi – buone classi – allora dobbiamo scriverle in modo tale da incapsulare correttamente i loro dati. E incapsulamento è in realtà solo una parola "grande" che si riferisce all’idea di gestire le proprie responsabilità (o tenere traccia dei propri dati).

Quindi, ad esempio, se stessimo scrivendo una classe per rappresentare un post di WordPress, avremmo una classe denominata Post con proprietà come publish, update, delete,  postData, publishDate, lastUpdatedData, DeleteDate e così via.

Quindi avremmo funzioni progettate specificamente per agire su un’istanza della  classe Post.

Caso in questione, potremmo…

• pubblicare,
• aggiornare,
• o eliminare un post

Questi metodi saranno probabilmente esposti in modo tale che altre classi possano trarne vantaggio. Inoltre, questi metodi probabilmente trarranno vantaggio anche da altre proprietà come publishDate o DeleteDate.

Ed è qui che entra in gioco il concetto di visibilità. Nella programmazione orientata agli oggetti, l’incapsulamento non si riferisce solo all’idea delle informazioni che una classe contiene, ma anche al modo in cui espone i dati.

Questi vengono eseguiti in tre modi, tutti definiti di seguito:

1. le proprietà e le funzioni pubbliche sono disponibili per l’utilizzo da parte di chiunque; tuttavia,  le proprietà pubbliche di  solito non sono esposte. Al contrario, ci assicuriamo che possano essere modificati con un metodo pubblico .
2. le proprietà e le funzioni protette sono disponibili per essere utilizzate dalla classe e da qualsiasi altra classe che eredita le informazioni da essa. Questo sarà discusso in modo più dettagliato nel prossimo post.
3. le proprietà e le funzioni private sono quelle destinate esclusivamente ad essere utilizzate nel contesto di una data classe. Queste possono essere proprietà utilizzate per tenere traccia degli stati interni o dei metodi utilizzati per funzionare come funzioni di supporto per le funzioni pubbliche per completare il proprio lavoro.

Continuando con questa serie, vedremo il ruolo che ciascuno di questi svolge nello scrivere classi chiare, facili da seguire e ben strutturate.

Per ora, però, è importante capire che queste parole, public, protected e private, vengono chiamate modificatori di visibilità perché, come si può constatare, gestiscono la visibilità di un metodo o di una proprietà rispetto alla sua classe e al classi che ereditano da esso e che interagiscono con esso.

Parlando di eredità, ne parlerò nella prossima parte di questa serie.

Astrazione, incapsulamento e WordPress

La cattiva notizia: lezioni in WordPress

Ecco il punto: in WordPress vediamo spesso classi molto, molto grandi. Questa non è una buona cosa. In effetti, questi sono anti-modelli chiamati classi di divinità (l’idea è che hai una singola classe che sa tutto).

E quando hai una classe divina, sembra conveniente perché puoi concentrare tutte le funzionalità in un unico posto. Ma

• è difficile da testare,
• non scala,
• non funziona bene con un’altra classe (per non parlare di classi o librerie di terze parti),
• non si adatta bene al cambiamento.

In definitiva, quando lo fai, non stai eseguendo la programmazione orientata agli oggetti. Stai prendendo funzioni e le inserisci in una classe. E vogliamo allontanarci da quello.

La buona notizia: lezioni di scrittura su WordPress

Ciò solleva una domanda, tuttavia: perché provare a imparare la programmazione orientata agli oggetti con WordPress se non è un solido esempio di programmazione orientata agli oggetti?

Questo perché puoi ancora scrivere un buon codice orientato agli oggetti su WordPress. Può ancora interagire bene con WordPress e può ancora giocare bene con molti altri aspetti di WordPress.

So che sembra controintuitivo, ma mentre ci addentriamo più a fondo nella scrittura di codice orientato agli oggetti su WordPress, questo dovrebbe diventare chiaro.