Perché esistono le interfacce: supportare i comportamenti dichiarati

In un senso più ampio, qualsiasi interfaccia è un meccanismo con cui qualcosa interagisce con qualcos'altro. Ad esempio, un telecomando TV è un'interfaccia remota. Un cane comprende ed esegue i comandi, il che significa che il cane supporta un'interfaccia vocale (di controllo). Per riassumere, possiamo dire che un'interfaccia è un modo standardizzato per far interagire due cose, dove entrambe le parti conoscono lo standard. Quando una persona dice a un cane di "sedersi", il suo comando fa parte di un'«interfaccia di controllo vocale del cane», e se il cane obbedisce al comando, allora diciamo che il cane supporta l'interfaccia.

Così è nella programmazione. I metodi sono azioni eseguite su un oggetto, sui suoi dati. E se una classe implementa determinati metodi, allora «supporta l'esecuzione» di determinati comandi. Cosa otteniamo combinando i metodi in un'interfaccia?

1) Ogni interfaccia , proprio come una classe , ha un nome univoco. Entrambe le parti possono essere sicure al 100% che l'altra parte supporti l'esatta interfaccia che conoscono e non un'interfaccia simile.

2) Ogni interfaccia impone determinate restrizioni su una classe che la supporterà. La classe (il suo sviluppatore) decide cosa farà quando vengono chiamati i metodi ereditati da un'interfaccia, ma il risultato dovrebbe essere entro i limiti di aspettative ragionevoli. Se ordiniamo a un cane di "sedersi" e poi si gira sul posto per 5 minuti e poi si siede, allora supporta l'interfaccia. Ma se invece ti prende per la gamba, difficilmente possiamo dire che supporti l'interfaccia. L'esecuzione del comando non ha prodotto il risultato previsto.

Diciamo che tu ei tuoi amici state scrivendo un gioco per computer. E sei stato incaricato di programmare il comportamento di un personaggio. Uno dei tuoi colleghi ha già scritto il codice per visualizzare tutti i caratteri sullo schermo. Un secondo collega, responsabile del salvataggio del gioco su disco, ha scritto il codice per salvare tutti gli oggetti del gioco in un file. Ognuno di loro ha scritto molto codice e creato un'interfaccia per interagire con quel codice. Ad esempio, potrebbe assomigliare a questo:

interface Saveable
{
 void saveToMap(Map<String, Object> map);
 void loadFromMap(Map<String, Object> map);
}

interface Drawable
{
 void draw(Screen screen);
}

class PacMan implements Saveable, Drawable
{
…
}

In altre parole, per supportare qualsiasi interfaccia (gruppo di interfacce), la tua classe deve:

1) Ereditarli

2) Implementare i metodi in essi dichiarati

3) I metodi devono fare ciò per cui erano destinati.

Quindi il resto del codice del programma, che non sa nulla della tua classe e dei suoi oggetti, può funzionare con la tua classe.

"Perché il codice non può sapere nulla della mia classe?"

"Supponiamo che tu abbia preso il codice da un programma che qualcuno ha scritto un anno fa. Oppure supponi che i tuoi amici abbiano acquistato/concesso in licenza il motore di gioco da qualcun altro. Hai un codice funzionante per il gioco. Migliaia di oggetti che interagiscono tra loro. E loro può facilmente interagire correttamente con i tuoi oggetti se fai in modo che l'interazione avvenga attraverso le interfacce che le tue classi hanno correttamente implementato."

"Lontano! Non sapevo che fosse possibile."

"Tutti i grandi progetti funzionano così. La gente ha smesso di scrivere da zero molto tempo fa."

Inoltre, le persone non reinventano ogni volta la matematica e l'alfabeto. Invece, studiano tutto ciò che è stato inventato prima di loro.