Classi astratte, parte 2 – Classi astratte e interfacce

Nel post precedente di questa serie, ho esaminato:

• le basi delle classi astratte,
• come implementarli,
• e fornito esempi di codice funzionante.

E anche se penso che la comprensione delle classi astratte sia la chiave per gettare solide basi per la programmazione orientata agli oggetti, vedo spesso che può creare confusione quando si tratta di confrontarle con le interfacce e sapere quando usarle.

Classi astratte e interfacce

Quindi, in questo post, condividerò:

• un rapido aggiornamento su cosa sono le interfacce,
• cosa sono le classi astratte,
• e poi come sapere quando usarne uno sull’altro.

Questo non dovrebbe essere un articolo ad alta intensità di codice, ma dovrebbe aiutare a sapere quando scrivere codice di un certo tipo per organizzare meglio i tuoi progetti.

1 Interfacce

Ricordiamo che quando si parla di interfacce, usiamo anche il termine "programmazione su un’interfaccia" con l’idea che l’interfaccia definisce i metodi che una classe deve implementare per adempiere al "contratto" con detta interfaccia.

Il codice utilizzato per dimostrare un’interfaccia di base era:

<?php

interface iCache 
{
  public function set($key, $value);
  public function get($key);
  public function has($key);
}

Ma ricorda, lo scopo dell’interfaccia non è definire dopo che il codice è stato scritto. Invece, è uno strumento utilizzato per progettare ciò che le classi dovrebbero implementare se seguono un determinato paradigma o se richiedono un determinato insieme di funzioni.

Cioè, se hai intenzione di progettare un insieme di classi che funzionano con la memorizzazione nella cache, non scrivi prima le classi. Prima scrivi l’interfaccia, quindi le classi implementano detta interfaccia.

L’idea è che tutte le classi che implementano l’interfaccia avranno tali funzioni.

2 Classi astratte

Le classi astratte, invece, ci permettono di fare due cose:

1. implementare funzionalità che possono essere utilizzate dalle sottoclassi,
2. implementare le firme dei metodi che le sottoclassi devono implementare.

Questo potrebbe sembrare un po ‘incongruente all’inizio, ma considera questo:

Quando hai una classe di un certo tipo che avrà funzionalità coerenti indipendentemente dalla sottoclasse, la funzionalità va nella classe astratta. Quando altri metodi devono avere la loro implementazione di un metodo, devi semplicemente fornire la firma del metodo e contrassegnarla come abstract.

Ecco un esempio di un post precedente:

Ora, questo ci cattura tutti dagli esempi precedenti e dalle cose precedenti su cui dobbiamo concentrarci per quanto riguarda le interfacce e le classi astratte, ma per alcuni questo non fornisce ancora molta chiarezza.

In particolare, questo ancora non risponde alla domanda: come decidiamo quando usare una classe astratta e quando usare un’interfaccia?

In apparenza, può sembrare un po’ confuso, ma ci sono alcune cose che puoi usare per prendere una decisione.

Quando li usiamo ciascuno?

Ricorda che quando si tratta di programmazione orientata agli oggetti, possiamo suddividerla in tre modi distinti:

• Le lezioni rappresentano una cosa. Puoi considerarli un sostantivo.
• Gli attributi o le proprietà sono come gli aggettivi. Descrivono l’oggetto o qualcosa che l’oggetto può contenere.
• I metodi o le funzioni sono come i verbi. Descrivono cosa possono fare gli oggetti.

Ora, quando si tratta di un’interfaccia, pensa a cosa fa l’interfaccia: descrive, senza implementazione, cosa può fare un oggetto. E quando si tratta di una classe astratta, descrive cos’è un oggetto durante il runtime.

In altre parole, una buona regola pratica è che se è necessario fornire un insieme di comportamenti per un oggetto, un’interfaccia è la strada da percorrere. Se hai bisogno di descrivere cos’è un oggetto, usa una classe astratta.

Per le classi astratte, farei anche un ulteriore passo avanti e direi che aiuta a descrivere un livello base di dati che descrive un oggetto o cosa potrebbe memorizzare oltre a un livello base di funzionalità.

Hai un esempio?

Come con la maggior parte del contenuto in ciascuno di questi post, provo a fornire esempi anche se non è specificamente fatto nel codice. Forse questo aiuterà a spiegarlo ancora di più:

• Le interfacce non hanno implementazione. Garantiscono solo ciò che farà una classe.
• Le classi astratte dovrebbero avere un livello base di implementazione. Questo dovrebbe rappresentare ciò che una classe può tenere e fare ma non è completo. Richiedono un po’ più di implementazione dalla sottoclasse.

Quando lavori con codice orientato agli oggetti, spero che questo aiuti a fornire alcune linee guida su quando usare cosa. In caso contrario, non esitare a lasciare un commento (qualcosa che i membri hanno il permesso di fare :).

Inoltre, lo vedremo in pratica quando arriveremo a scrivere codice orientato agli oggetti (in particolare per WordPress, ma non sempre).