Quando si dice "un'interfaccia di classe":
Fa riferimento a tutti i metodi get e set - o si riferiscono solo alle firme dei metodi e ai tipi restituiti, senza l'implementazione interna di questi metodi? (Aka, l'implementazione di un metodo 'get' non è considerata parte dell'interfaccia, ma piuttosto parte dell'implementazione interna della classe.L'interfaccia è il tipo di ritorno per quel metodo e la firma di quel metodo).
Se stai facendo interfacce correttamente, l'interfaccia è costituita dalla firma dei metodi e dalla semantica del modello dei metodi. Questa seconda parte è importante - quasi certamente non vorreste un metodo di SumTheColumnContents per lanciare in realtà un attacco termonucleare preventivo sul pesce rosso pregiato dei vicini, ma non è tutto ciò che è possibile applicare al compilatore. (Determinare quando due pezzi generali di codice fanno la stessa cosa è un problema estremamente difficile, poiché include il famoso problema di stallo, e in effetti le sfide più interessanti nelle prove matematiche, come sotto-problemi .) Quindi tu devono essere ben educati e non andare in giro a fare cose cattive. Naturalmente, questo è solo il buon vecchio Principio di sostituzione di Liskov con una classe completamente astratta come la superclasse; se la semantica delle sottoclassi è molto diversa, non sarà intercambiabile tra loro anche se la firma è la stessa.
Questo è tutto indipendente dal modo in cui un linguaggio di programmazione casuale descrive o implementa un'interfaccia. È un concetto molto più generale di quello. (Sì, alcuni li chiamano "interfacce" e altri li chiamano "protocolli", e alcuni li chiamano semplicemente "superclassi astratte". L'idea è sempre la stessa.)
L'interfaccia non include i dettagli di implementazione, per definizione. È il modo in cui interagisci con la 'cosa', così si potrebbe creare un'altra 'cosa' che fa la stessa cosa, anche se le sue interiora sono completamente diverse.
Il problema con i metodi get e set è che ti dicono cosa stanno facendo alle interiora della cosa. Un metodo chiamato .getZebra() mi dice che c'è una variabile chiamata zebra in quella cosa; altrimenti sarebbe stato chiamato .zebra() , e non sapresti se è memorizzato o calcolato o cosa.
Se qualcuno vuole venire avanti e reimplementare la tua cosa in modo diverso (eventualmente tu, più avanti), e la tua interfaccia è cosparsa di getter e setter, allora c'è una scelta di a) rompere l'interfaccia, b) usando le stesse variabili per rappresentarlo, vincolando il disegno inutilmente, o c) simulando la presenza di quelle variabili nel nuovo codice, complicando inutilmente il disegno. È possibile che tu possa essere fortunato e che la tua interfaccia sia carina e non dovrai fare quelle cose, ma se usi nomi come getX() e setY() , stai pensando in termini di variabili x e y che tu hai, non ciò che rappresentano astrattamente.
I setter costringono anche il tuo oggetto a essere mutabile, e il significato di ciò che stai cercando di fare potrebbe non essere necessario.
L'implementazione di getter e setter non è garantita dalle parole 'get' o 'set', quindi tecnicamente puoi dire che fanno parte dell'interfaccia di classe e che quindi non c'è violazione di incapsulamento, ma in realtà non c'è. I programmatori usano le parole per dire qualcosa, e quando mettono 'get' o 'set' all'inizio del nome di un metodo, dicono "questo è implementato come variabile".
L'interno e l'esterno di una classe (o di un oggetto) si trovano a diversi livelli di astrazione; l'interno è tutto su come è fatto, l'esterno è tutto su ciò che può essere fatto. La denominazione dovrebbe riflettere la distinzione.
Se ti ritrovi a scrivere un oggetto che ha molti getter e setter e non riesci a trovare un modo ragionevole per rinominarli, probabilmente hai una struttura dati, non un oggetto.
L'interfaccia di una classe è essenzialmente ciò che è visibile ad altre classi che lo utilizzano.
L'interfaccia di una classe sarebbe quindi la dichiarazione di tutti i metodi pubblici e le variabili che espone. Non includerebbe i dettagli di implementazione di ciascun metodo.
Dove una classe ha protetto (o pacchetto privato per Java) metodi e variabili, allora dovrebbero essere considerati parte dell'interfaccia, dato che possono essere accessibili anche da altre classi, anche se con alcune restrizioni.
Leggi altre domande sui tag object-oriented interfaces