I secondi due pilastri dell’OOP

Come ho detto nel primo post di questa serie, sentirai spesso parlare dei tre pilastri della programmazione orientata agli oggetti. Potresti anche sentire parlare dei quattro pilastri della programmazione orientata agli oggetti.

E non è che ce ne siano in totale sette o qualcosa del genere. Invece, si tratta più di ciò che la gente considera fondamentale per l’OOP: ci sono tre o quattro concetti principali?

Si può dedurre dall’articolo precedente (per non parlare del titolo), credo che siano quattro.

E in questo post, tratterò gli ultimi due:

• Eredità,
• e Polimorfismo

Se hai eseguito qualsiasi tipo di programmazione orientata agli oggetti prima di leggere questo articolo, probabilmente avrai sentito parlare di almeno uno di questi.

Indipendentemente da ciò, diamo un’occhiata a ciascuno di essi in modo più dettagliato.

Altri due pilastri dell’OOP

Prima di saltare in ognuno di questi, voglio essere sicuro che tu sia coinvolto in ciò che abbiamo trattato finora.

Una parola sull’analisi

Non soffermerò il punto, ma l’intera ragione per cui ora parlo di fondamenti orientati agli oggetti è perché ci stiamo muovendo in una fase diversa di questo materiale. Abbiamo iniziato coprendo la fase di analisi che comprendeva:

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

Ora allo sviluppo

E ora siamo alla fase di sviluppo. Alcuni potrebbero chiamarlo fondamentali (ma sono contento che non puoi fare un buon sviluppo senza i fondamenti, quindi c’è quello (.

Se non hai letto il post precedente, ti consiglio di farlo prima di continuare in quanto copre i concetti di astrazione, incapsulamento e come si collega a WordPress.

3 Eredità

Il concetto di eredità è abbastanza facile da seguire. Cioè, una classe può ereditare gli attributi di un’altra classe. Farò alcuni esempi di questo in un momento, ma permettetemi di fornire una definizione di lavoro ai fini di questo post:

L’ereditarietà si riferisce all’idea che una classe, sebbene abbia la propria implementazione, eredita letteralmente proprietà, funzioni e implementazione generale da una classe padre.

Esempio 1: un documento

In termini molto semplici, supponiamo che tu abbia una classe chiamata Document e che un documento abbia un titolo e un contenuto. Poi c’è una sottoclasse di documento che ha attributi per una data e un’ora. Potremmo chiamarlo un PostDocument o un PageDocument.

Cioè, il PageDocument eredita le proprietà e gli attributi di Document aggiungendo anche la propria implementazione. Ha senso?

In caso contrario, non preoccuparti. All’inizio non fa sempre "clic", quindi diamo un’occhiata a un altro esempio.

Esempio 2: un messaggio

Diciamo che abbiamo una classe Messaggio. Un messaggio ha tipicamente due proprietà:

• 1 Un mittente,
• 2 Un destinatario.

È giusto dire che ci sono diversi tipi di messaggi, giusto? Cioè, forse abbiamo un EmailMessage o forse abbiamo un TextMessage.

Un EmailMessage ha ancora un mittente e ha ancora un destinatario ma ha molto di più, giusto? Ha cose come:

• una riga dell’oggetto,
• un allegato facoltativo,
• un altro insieme di mittenti a cui è stato inviato,
• supporto per copiare altri nel messaggio pubblicamente o privatamente,
• e altro ancora.

Un TextMessage d’altra parte non avrà necessariamente tutto quanto sopra. Supponiamo che stiamo parlando di un messaggio SMS di base (rispetto a un messaggio di testo RTF in qualcosa come Hangouts, Telegram, iMessage o qualsiasi altra cosa sia là fuori).

Questa classe:

• essere legato a un numero di telefono,
• può includere un gruppo di altri destinatari tutti pubblici,
• un vettore (che è un provider di telefonia mobile),
• un numero massimo di caratteri che può contenere
• la possibilità di dividere un singolo messaggio in più messaggi se il numero massimo di caratteri supera un determinato numero di caratteri.

Ma solleva ancora domande su proprietà e metodi (o, più in generale, implementazione, giusto?)

Una parola sull’implementazione

Quando si tratta di programmazione orientata agli oggetti, abbiamo quelli che chiamiamo modificatori di accesso. Forse li hai letti altrove chiamati, diciamo, modificatori di visibilità o qualcosa del genere.

È tutto uguale.

In breve, questi modificatori possono essere definiti come:

Parole chiave che controllano ciò che le altre classi hanno accesso alle informazioni a portata di mano.

Fortunatamente, questa parte è semplice da capire:

• le proprietà e le funzioni private sono accessibili solo alla classe in cui sono definite. Ciò significa che PostDocument non può utilizzare nulla in Document che è contrassegnato come privato. A tutti gli effetti, PostDocument non è nemmeno a conoscenza dell’esistenza di queste informazioni.
• le proprietà e le funzioni protette sono accessibili alla classe in cui sono definite ea qualsiasi classe che discende. Cioè, qualsiasi classe che eredita i dati dalla classe base o dalla classe genitore ha accesso ad essa. Quindi, a differenza dei dettagli di implementazione privati, PostDocument può accedere alle informazioni da Document se è contrassegnato come protetto.
• le proprietà e le funzioni pubbliche sono accessibili a chiunque. Questo non ha nulla a che fare con l’ereditarietà, in realtà, ma più con l’incapsulamento, semmai. Invece, si tratta di decidere a cosa vogliamo che altri oggetti accedano.

Quindi, come viene gestita l’implementazione? Questo varia da lingua a lingua, ma PHP non supporta quella che viene chiamata "ereditarietà multipla". In poche parole, una determinata classe in PHP può ereditare (o estendere) solo un’altra classe. Non più classi (alcune lingue lo supportano).

Quando si estende una classe, la sottoclasse eredita tutti i metodi pubblici e protetti dalla classe padre. A meno che una classe non sostituisca questi metodi, manterranno la loro funzionalità originale.

Nel nostro esempio, non possiamo introdurre un’altra classe come WrittenDocument che eredita da PageDocument così come PostDocument. O è l’uno o l’altro. E vale la pena notare che se eredita da PostDocument, eredita anche le informazioni da Document perché è una sottoclasse di una sottoclasse di una classe.

4 Polimorfismo

Ora che abbiamo una definizione di base di ereditarietà, possiamo parlare di polimorfismo. La buona notizia è che è una parola grossa e strana per un concetto molto semplice.

La cattiva notizia è che non abbiamo parlato di interfacce o di classi astratte. Questi stanno arrivando ma sono considerati parte dei quattro pilastri, quindi non preoccuparti per loro in questo momento.

Invece, pensaci in questo modo:

Il polimorfismo ci consente di fare riferimento a una classe di un tipo quando può essere dichiarata come un altro tipo.

Potrebbe ancora creare confusione, ma ricordi il nostro esempio di messaggio sopra? Possiamo creare un’istanza di una classe SMSMessage che estende la classe Message e quindi chiamare determinati metodi su di essa.

L’SMSMessage può avere un metodo che ha la classe Message. E se la classe è stata istanziata come un’istanza della classe SMSMessage, chiamerà quel metodo. Allo stesso modo, se non ha un metodo ma la sua classe padre, Message, ce l’ha, chiamerà quel metodo.

A volte, è più facile capirlo nel codice, quindi facciamolo.

Per prima cosa, definiamo la nostra classe Messaggio :

<?php
class Message
{
  public function send()
  {
    echo "This message is sent from the Message class.n";
  }

  public function receive()
  {
    echo "This message was received from the Message class.n";
  }
}

Quindi definiamo la nostra classe SMSMessage. Si noti che non ha una funzione di ricezione(). Questo sarà importante momentaneamente:

<?php
class SMSMessage extends Message
{
  public function send()
  {
    echo "This message is sent from the SMSMessage class.n";
  }
}

Ora istanziamo la nostra classe Message e chiamiamo alcuni metodi:

<?php
$message = new Message();
$message->send();
$message->receive();

E facciamo lo stesso usando la classe SMSMessage:

<?php
$message = new SMSMessage();
$message->send();
$message->receive();

Se vuoi l’intero script, puoi vederlo qui, scaricarlo ed eseguirlo localmente.

Ereditarietà, polimorfismo e WordPress

Ecco il take away (e lo esploreremo di più quando entriamo nelle interfacce e nelle classi astratte): quando una classe estende un’altra classe e non ha i dettagli di implementazione che ha la sua classe genitore, verrà utilizzata l’implementazione del genitore.

Un altro modo di pensare è "allargare la catena di comando". Inizierà con la classe più bassa di quella che abbiamo creato. Nel nostro esempio sopra, questo è SMSMessage. Se non lo trova lì, passerà alla classe che estende. (E se non lo trova lì e quella classe estende una classe, proverà lì.)

L’intera cosa polimorfica è questa: abbiamo istanziato una classe di un tipo, SMSMessage, ma sta usando l’implementazione di una classe di un altro tipo (che eredita, sì, ma è comunque diverso).

Corsi di scrittura su WordPress

Infine, vorrei lasciarvi con questo: ho accennato qualcosa di simile a questo nel post precedente ma voglio ribadirlo qui.

Indipendentemente dal numero di questi concetti utilizzati dal core di WordPress, non importa perché possiamo scrivere codice orientato agli oggetti di alta qualità su WordPress che interagisce con WordPress e che funziona bene con WordPress (e altri codici di terze parti, non sempre, ma molte volte).

Cosa succede dopo?

Successivamente, esamineremo interfacce e astrazioni.

Questi sono ancora fondamentali per la programmazione orientata agli oggetti, ma se hai compreso i due post precedenti, sei pronto per una solida esperienza con i concetti imminenti.

E se no, non preoccuparti! Puoi sempre parlarne nei commenti o possiamo parlarne di più via e-mail.