Quando vedo frammenti di codice comevirtuali Metodi di estensione nel prossimo Java 8 rilascio
interface A {
void a();
void b() default { System.out.println("b"); };
void c() final { System.out.println("c"); };
}
Ho una domanda. Non abbiamo già abbastanza sh * t in Java? Perché uno potrebbe aver bisogno di questo?
suggerisco di guardare in questa conferenza: http://medianetwork.oracle.com/media/show/16999
Questo spiega tutto. La cosa più interessante da fare è consentire a un'interfaccia di evolversi senza riscrivere l'intera base di codice. Questa è la chiave per consentire ad una grande base di codice di evolversi e non diventare sempre più paralizzata.
Credo che il concetto di "metodi di estensione" non sia altro che l'ultima possibilità di hackerare/correggere le API mal progettate che sono state esposte al "mondo esterno". Solo zucchero sintattico.
Sì, tutte quelle API mal progettate i cui progettisti non erano dotati di chiaroveggenza o che non potevano effettivamente progettare la loro interfaccia in modo diverso perché alcune funzioni non esistevano già;) – Voo
@Voo I progettisti dell'API non hanno bisogno di essere chiaroveggenti rendersi conto che potrebbero esserci metodi che devono essere aggiunti in seguito. Avrebbe potuto usare classi astratte, sebbene il linguaggio sia carente in quanto non consente la definizione di una classe astratta "pura" senza aggiungere il bagaglio indesiderato di compatibilità binaria di un'interfaccia. –
Oh, "metodi di difesa" in realtà. –
Ne abbiamo bisogno perché renderà i ragazzi della Scala assolutamente furiosi. Hanno già una funzionalità piuttosto simile sotto forma di "tratti", quindi ora dovranno farli lavorare insieme con questi.
Fare incazzare ragazzi Scala è letteralmente la priorità più alta nello sviluppo del linguaggio Java.
In realtà, penso che i metodi di estensione virtuale siano [un'implementazione molto incompleta] (http://codecrafter.blogspot.ca/2012/06/java-8-virtual-extension-methods-are.html) di tratti e potrebbero dipingere in un angolo. –
Ovviamente Jordão è un ragazzo scala, quindi il piano funziona. – ryber
+1 Mi ha fatto ridere! –
Questo è ottimo perché consente a chi scrive API di estendere le interfacce post-hoc senza causare NoSuchMethodErrors. Inoltre, si forniscono implementazioni predefinite per i metodi in V2 per le classi compilate con V1; il codice funziona come un fascino. Ciò consente anche di sovrascrivere l'implementazione predefinita nelle classi compilate con V2 come al solito e rende ridondanti le interfaccie numerate. Lo considero anche superiore ai metodi di estensione del sito di utilizzo.
quindi è fondamentalmente un aiuto per gli scrittori jdk, giusto? –
No, è un aiuto per gli scrittori di librerie, che ora possono estendere le loro interfacce (API) nella V1.1 senza doverlo rinominare alla 2.0 e richiedere una ricompilazione. –
come mai? hanno sicuramente bisogno di cambiare il codice da qualche parte. –
È previsto che Java 8 conterrà alcune forme di lambda e supporto di chiusura, che rappresenterebbero un grande passo per la modernizzazione del linguaggio Java. Il problema è che le librerie esistenti basate su interfacce, come il framework di raccolta, non saranno in grado di utilizzare direttamente queste nuove funzionalità. Non è possibile aggiungere un metodo a un'interfaccia senza rompere le implementazioni esistenti, sarebbe semplice non compilare più.
Avere i lambda, ma non essere in grado di usarli facilmente con le raccolte standard, sarebbe una grande delusione per gli sviluppatori java. Per integrare lambda nelle raccolte standard, metodi come forEach, map o filter sarebbero altamente desiderabili.
La soluzione a questo problema è aggiungere un'altra funzionalità, i metodi di estensione, che definiscono un'implementazione predefinita di un metodo in un'interfaccia. Sottoclassi esistenti utilizzerebbero il metodo predefinito, ma è anche possibile sovrascrivere il metodo con un'implementazione specializzata e possibile migliore.
Ulteriori informazioni sulla proposta del metodo di estensione sono disponibili su Java Enhancement Proposal 126.
E proprio per gli stessi motivi per cui saranno così estremamente utili per lambda, aiuteranno anche altre API. Infine niente 'interfaccia X',' X2', .. più! A proposito di tempo. – Voo
Questa è una grande estensione imo, porterà Java più vicino al mondo dell'eredità multipla senza tutti i suoi dettagli di implementazione disordinati. – Perception
@Perception "... senza tutti i suoi dettagli di implementazione disordinati ..." come esattamente? –
Concatenamento del concatenatore, Scontro potenziale del nome, ambiguità polimorfa, non parlo troppo della complessità aggiuntiva che dovrebbe essere definita nel compilatore. Tutti i motivi per cui i mixin sono più popolari dell'ereditarietà multipla in un sacco di lingue moderne e di cosa questa caratteristica mi ricordi di più. – Perception