Ciao, questo è determinato al lotto.
Ora esaminiamo l'articolo 52 che dice riferirsi agli oggetti tramite le loro interfacce.
Fondamentalmente, ciò che gli articoli dicono sono quando possibile tenta di usare un'interfaccia come tipo di riferimento in
tutti i tipi di dichiarazioni variabili e anche usarli come tipi di ritorno del metodo.
Diamo un'occhiata a un esempio.
Consideriamo questo frammento di codice con il metodo foo che ha un singolo parametro disattivato da idlest che
è un bus concreto.
Il problema con questo è che non possiamo solo invocare questo metodo con un idealista che non possiamo
passare un'altra implementazione simile.
Tuttavia se avessimo il tipo di parametro come una lista che è un'interfaccia allora potremmo quanto velocemente sono
de-list o se necessario.
In futuro potremmo passare qualsiasi linguista o forse anche una lista che provenga dalla libreria Apache Commons, che sappiamo essere
una gerarchia di ereditarietà completamente diversa, quella di Lister rispetto all'API di luglio standard.
Ma l'oggetto che viene passato proviene da una gerarchia di ereditarietà completamente diversa
e siamo in grado di farlo solo perché il trialista implementa l'interfaccia di lista.
Quindi stai dicendo che un vantaggio è che possiamo cambiare le implementazioni se necessario.
Ma perché dovremmo cambiare l'implementazione.
Un motivo comune è che la nuova implementazione offre prestazioni migliori.
Ovviamente conosciamo anche i vantaggi polimorfici dell'uso di un supertipo.
Otteniamo un codice flessibile che è meno suscettibile di modifiche in quanto possiamo passare a nuovi tipi di oggetto che non ci
sono quando il codice è stato originariamente scritto.
OK, così possiamo passare nuove implementazioni e il codice sarà anche molto più pulito.
Ciao mi accorgo che ora stiamo dicendo che si tratta di un cavo flessibile al posto del semplice codice
flessibile.
E questo perché con le interfacce.
Gli oggetti possono provenire da qualsiasi gerarchia di ereditarietà che non è necessario che provengano dallo stesso
albero di ereditarietà dell'interfaccia.
Questo in genere non è possibile con il processo concreto o astratto poiché le classi sono specifiche dell'implementazione
che non sono in genere confinate a un albero di ereditarietà che in genere non si vede
essere senza cena in un albero di ereditarietà diverso, ma con le interfacce definiamo un contratto che è un specifica
su Quindi è molto più generico.
Le implementazioni possono arrivare da qualsiasi luogo.
Esaminiamo anche un paio di eccezioni.
Quindi dovremmo andare con le classi piuttosto che con le interfacce. Un'eccezione è quando non c'è un'interfaccia fatta
in questo caso.
Prova ad usare la classe meno specifica.
Il secondo scenario è che potrebbe esserci un'interfaccia, ma potremmo dover usare una sottoclasse specifica come un
tipo di riferimento in quanto la sottoclasse potrebbe definire un comportamento specializzato sotto la squadra motard Neech tale
comportamento specializzato.
In tal caso dobbiamo usare la sottoclasse come un tipo di riferimento. Quindi questo è su questo oggetto.
Quando possibile, cerca di utilizzare un'interfaccia come tipo di riferimento, a meno che non ci siano alcune eccezioni
come quelle indicate qui.
Grazie.