Ciao, questo è il momento.
E bentornato.
Continuiamo la nostra discussione sull'interfaccia in quanto vi sono pochi altri dettagli importanti di cui abbiamo bisogno
di discutere.
Come una classe, un'interferenza può anche estendere quell'interfaccia.
Sappiamo che estendendo la classe stiamo creando una classe specializzata in classi specializzate, in genere
aggiungiamo nuove variabili sui metodi.
Oltre a ciò che eredita.
Allo stesso modo se qualcosa è anche in alcuni metodi astratti specializzati ON-OFF, possono anche aggiungere uno o più.
Le variabili finali relative all'esempio qui mostrato provengono dall'API Java in cui l'interfaccia estende solo la connessione
dell'interfaccia ma queste interfacce fanno parte del lavoro. Cosa stai facendo il pacchetto
underbred discuterle in dettaglio e il capitolo framework delle collezioni non ha una classe che implementa il
qualcosa è come implementare tutti i metodi astratti.
Sii chiaro sia nelle sub che nelle super interfacce.
Esiste una classe chiamata RLDS e implementa l'interfaccia elenco che vedi qui.
Quindi implementa metodi astratti dal botanico così come le interfacce di raccolta sono più illecite che
è molto importante saranno discusse più avanti nel capitolo quadro della raccolta.
Un'altra cosa da notare è che una classe può solo implementare un'interfaccia che non può estendere un'interfaccia.
Può solo estendere un'altra classe in modo che la classe possa estendere un'altra classe su quell'interfaccia che
può estendersi a tale interfaccia creando così versioni più specializzate.
Tuttavia, a differenza delle classi, un'interfaccia può estendere più interfacce.
Ecco un altro esempio dell'API di luglio in cui un'interfaccia si estende alle interfacce
per facilitare l'aggiunta di nuovi metodi appropriati per una combinazione.
Ciò significa che ognuna delle superinterfacce specifica le proprie capacità uniche, ma l'interfaccia secondaria fornirebbe
metriche che rappresentano le capacità di bordo delle super interfacce su questo non si incontrano
comunemente.
Buttman è necessaria una tale flessibilità interfacce così un passaggio Norburn che discute di classi astratte.
Hai detto che una proposizione secondaria astratta non deve sovrascrivere i metodi astratti definiti nella superclasse.
Lo stesso vale se una sottoclasse astratta implementa un'interfaccia.
Non è necessario implementare metodi astratti dichiarati nell'interfaccia che possono essere eseguiti da
sottoclassi della sottoclasse astratta.
Quindi, tieni a mente che una classe astratta può anche implementare quell'attitudine.
Non deve essere solo una normale polvere di cemento può essere una classe astratta per un esempio di Here in cui abbiamo
due interfacce A e B.
Dichiarazione di un nome di metodo astratto identico.
La classe X che implementa entrambe queste interfacce fornisce un'implementazione per loro e che
per ora ricordiamo che prima, quando abbiamo qualcosa di simile, abbiamo il problema del problema di Biman hollower.
Lì era dovuto all'eredità multipla di identiche implementazioni materne.
Ma eccolo qui.
L'ereditarietà multipla di dichiarazioni di metodi identiche che non includono le terze implementazioni
sulla sottoclasse è obbligata a fornire loro quell'implementazione.
Quindi non avremo il problema fuori dal problema Diamon e questo è ed ecco uno scenario interessante.
Come nella precedente interfaccia di esempio, dichiara il metodo astratto foo l'agente non-nut B è una classe
completamente indipendente che fornisce una definizione di metodo per il metodo completo Zic per il calcestruzzo nella classe B.
In questo caso la sottoclasse X che implementa l'interfaccia ae estende la classe B non deve
fornire un'implementazione per la materia astratta.
Foo nell'interfaccia.
Il metodo foo definito allora B sarebbe sufficiente.
A meno che la classe X non la sostituisca.
Ora discutiamo un po 'sulle variabili dell'interfaccia.
Vediamo innanzitutto perché le variabili e le interfacce devono essere fermate.
È possibile trovare deve essere psicotico perché, come accennato in precedenza, le interfacce non sono istruttive.
Cioè sono apolidi.
Quindi le variabili dovrebbero essere accessibili qualificando i nomi delle variabili che il nome dell'interfaccia.
Questo è il nome dell'interfaccia seguito dal DOT che è seguito dal nome della variabile e che andrebbe
bene.
Poiché le interfacce sono contratti puri e stanno facendo in modo che affermi che ciò che vediamo va
bene al loro interno rimarrà tale.
Quindi è come un accordo impostato su un miglioramento o cambiamento di pietra.
Quindi se c'è una variabile con un certo valore allora quel valore non cambierà.
Quindi altre classi possono accedere a quella variabile in una variabile che rimarrà sempre la stessa.
Ad esempio, supponiamo di avere una tale azione del nome dell'interfaccia che dichiari un
brillante toro chiamato Sukses che è inizializzato alla quantificazione del volume, quindi vediamo se abbiamo una classe chiamata client.
A meno che tu non sappia che esiste una logica in cui il client si connette a qualche server
remoto che Konik con successo, la proprietà di cretin viene chiamata Sukses fino a quel punto in cui può utilizzare la variabile Sukses
nella connessione dell'interfaccia.
Quindi questo cross client si aspetterebbe che il valore del successo rimarrà sempre quantificato in quanto potrebbe
esserci qualche altro codice che utilizzerà questo valore restituito dal client di classe.
Ora se il valore della variabile Sukses viene modificato, potrebbe essere in violazione del contratto.
Quindi fa schifo come dichiarato in finale, abbiamo la certezza che non cambierà mai.
I Muhtar non sono stati qui perché il successo è un valore costante.
Sappiamo che il valore quantifico che il successo è inizializzato vet verrà copiato nell'istruzione scritta
nel clown della classe che il compilatore copierà quel valore nel bytecode di un clown della classe.
Finalmente vediamo come accedere a variabili con nomi identici da due diversi super-tipi.
Quindi qui abbiamo due interfacce A e B che definiscono entrambe una variabile chiamata Colligan e non la classe X ..
Implementa entrambi in B e come puoi vedere se la classe X accede a una variabile ma con quel nome semplice ottengono
un errore del compilatore in quanto il compilatore ovviamente non sa quale versione di valore usare.
Quindi c'è un nome di variabile in classe qui non mostrato nella prossima dichiarazione.
Vinnie per qualificare quello costante per risolvere l'ambiguità in questo caso stiamo accedendo al russo
e B ma solo se una di queste interfacce sta dichiarando la variabile vincolata e X verrà impostata direttamente.
Si noti inoltre che la variabile vocale è un tutto maiuscolo, poiché sappiamo che per convenzione le variabili finali
dello stocktake sono tutte le poliziotte separate da underscore.
Quindi non dimenticare la convenzione di denominazione.
Quindi questo è tutto.
Successivamente faremo morire le interfacce, dopo di che discuteremo le interfacce in modo più concettualmente, così da sapere
quando usarle.
E questa è la parte più importante.
Grazie.