Salve, è questo che non vogliono sapere, sappiamo capire come le interfacce possano essere utilizzate per
la sintassi non sono così semplici.
La cosa più importante da capire è quando utilizzare un'interfaccia.
È abbastanza comune vedere gli ingegneri di fronte a un dilemma se debbano codificare qualcosa come un'interfaccia o
come una classe astratta.
Ed è perché se una classe astratta ha solo metodi astratti, allora non è diversa da un'interfaccia.
Analogamente a Jella, otto interfacce possono includere metodi concreti e quindi non sembrano essere
diverse dalle classi astratte.
Quindi attraverso questo nella prossima lezione cercheremo di affrontarlo imparando come vengono tipicamente utilizzate
le interfacce.
In generale le interfacce possono essere classificate in due tipi.
Il primo passo può essere definito come il rappresentante delle interfacce.
Bene, il secondo tipo di Moxon.
E guardiamo ognuno di loro.
Vediamo solo rappresentare due interfacce rappresentate l'interfaccia definisce il comportamento che è rappresentativo di sottoclassi
che i metodi di interfaccia definiscono la funzionalità di base del sottoprocesso tali interfacce in genere vengono con
una o più implementazioni.
Se stai parlando di un'API pubblica come la libreria Java, non è comune che le implementazioni
provengano da API esterne.
Quindi i progettisti dell'API fornirebbero una o più implementazioni insieme all'interfaccia stessa.
Ecco un esempio dalla libreria Java.
Il nome dell'interfaccia è List.
Ha diverse implementazioni.
Quelli importanti sono mostrati qui, ma le implementazioni di underdose dell'interfaccia sono dal pacchetto di accordi
di Gelada, ma li studiano e il capitolo di framework delle collezioni l'interfaccia di lista rappresenta una struttura
di dati che memorizza tutta quella raccolta di elementi.
La chiave qui è il termine ordinato.
Quindi gli elementi sono ordinati.
In sintesi c'è una posizione di elementi nella lista ha un qualche significato qui.
Pertanto l'interfaccia include metodi che consentono di recuperare elementi o di essere recuperati e cancellati da
posizioni specifiche nell'elenco.
E quel tipo di accesso posizionale è rappresentato dal comportamento definito dall'interfaccia Elenco.
Quindi tutte le implementazioni di liste avranno anche questo comportamento di accesso posizionale.
Come accennato in precedenza, non è comune che le interfacce auto-rappresentate di sottoclassi provengano dall'esterno
dell'API.
Ma quando arriveranno, di solito è da qualche altra API popolare che fornisce un'implementazione migliore.
Ad esempio, puoi vedere qui che l'interfaccia di lista dal corpo Jawaani standard ha implementazioni da
altre API è come Google scuola siamo un Apache Commons Apache Commons doc per le affermazioni trialiste che è un
alternativa migliore per fare una lista collegata che fa parte dell'API standard di luglio e
implementa anche l'interfaccia dell'elenco.
Quindi, non avrebbero intenzione di far scoppiare lo sviluppo di alcuni software proprietari in genere
non implementare un tale prisma per le interfacce. L'argomento di questo non è qualcosa che è limitato al pubblico.
Sì, possono anche essere dichiarati e software proprietario.
Ecco un esempio di un componente di integrazione dei dati che aggrega i dati relativi
ai libri provenienti da fonti diverse che rappresentano un nuovo libro di interfaccia progettato per definire un protocollo comune
dichiarando metodi come ottenere dettagli e ottenere recensioni ottenere i dati sarebbe irresponsabile recuperarlo è come gli autori
di Tipler di descrizione e così via.
Dato che l'ISBN non è pubblicato su un libro, le recensioni positive sarebbero irresponsabili nel recuperare le recensioni
per un determinato libro sull'implementazione sono specifiche per ogni origine dati e incapsulano informazioni su come interrogare le loro
fonti di dati e anche i risultati positivi restituiti da loro è bello se in futuro una nuova fonte deve
essere aggiunta e se è aggiunta da un nuovo programmatore, allora lui o lei dovrà supportare entrambe
queste questioni.
E questo è il vantaggio che otteniamo avendo un protocollo comune che è un protocollo comune che sta costringendo il programmatore
a fornire un'implementazione non comune per un libro su come il programmatore di Pitman esegua l'errata digitazione di un nome
di metodo.
Ad esempio, se il programmatore fornisce informazioni errate mentre il singolare viene sottoposto a revisione,
compagno accompagnerà la mancata implementazione delle revisioni astratte del motard.
Ciò consentirebbe al programmatore di aggiustare quella bibbia non-noce per vedere in che cosa ha senso la mescolanza, quindi
il secondo tipo di interfacce e queste sono interfacce che definiscono certe capacità che il sottoprocesso può
avere.
Quindi il sottoprocesso ha una propria identità.
Inoltre, quando implementano un mixin, annunciano anche che supportano ulteriormente la
capacità che l'interfaccia di mixin sta definendo.
Non che ci riferiamo a questa interfaccia come a un mixin in quanto consente alla
funzionalità che sta definendo di essere mescolata alla funzionalità di quella classe che sta implementando il Maxson delite definisce diverse
interfacce di mixin.
Unmix poiché sono un significato molto generico a differenza di quanto accade nel caso di due interfacce utente, le
API di self-doubt rappresentano tipicamente le classi che implementano tali interfacce.
OK.
In effetti, dal momento che non sono nuovo per noi, in realtà abbiamo usato un Maxson nel nostro ultimo diagramma di classe.
L'interfaccia condivisibile è un mixin.
Consideriamo la classe di bit qui.
Ha la sua identità principale che è un segnalibro ed è identificato da caratteristiche come l'altare di descrizione di ID
Deiter e così via.
Oltre ad avere la sua identità principale implementando il libro di classe con interfaccia condivisa, dichiara anche
di avere la capacità di essere condiviso.
L'interfaccia così condivisibile è un mixin e consente di combinare la funzionalità condivisa con la
funzionalità principale della classe.
Ricorda che dal momento che più B-class non implementa sparabili non ha quella capacità
aggiuntiva condivisibile.
Tipicamente, quando le persone parlano di interfacce, di solito associavano quella funzionalità come nel caso
di Moxon.
Ma come abbiamo visto le interfacce possono anche rappresentare sottoclassi di funzionalità essenziali offerte in questo esempio dimostra
la classe di libri che supporta molteplici funzionalità implementando comparabili sparabili su interfacce globali compatibilmente
compatibili con la libreria standard di luglio implementando classi di libri comparabili che dichiarano
che i suoi oggetti hanno capacità di essere confrontati tra loro e implementando Groeneveld
dichiara che gli oggetti hanno la capacità di restituire le proprie copie.
A rigor di termini, il prestito è un altro tipo di interfaccia chiamata interfaccia di
mercato che verrà discussa in seguito sull'interfaccia del kernel.
Non quello da un punto di vista della convenzione di denominazione.
MC dal momento che in genere e leggere il suffisso in grado come vediamo qui nel caso di condivisibile sono paragonabili.
Che tipo di sottolineare la loro capacità.
Quindi questo è tutto.
E abbiamo esaminato i due tipi di interfacce che possiamo definire concettualmente e che è molto importante
sapere.
È bello averlo fatto.
In seguito vedremo un elemento di doea efficace che parla delle interfacce di esecuzione da
preferire alle classi astratte e viceversa.
Grazie.