@Override annotaion nell'implementazione delle interfacce

[Kaamos]

Da Java 6 l'annotazione @Override si può applicare anche ai metodi necessari all'implementazione delle interface... ma a che serve? Se in Java 5 non si poteva e dopo invece si, suppongo l'abbiano aggiunta per un motivo, ma non mi viene in mente lo scenario in cui potrebbe essere utile. Ho cercato online in inglese ma non ho trovato motivazioni e le specifiche di Java non sono aggiornate, tant'è che riportano ancora che la suddetta annotazione se usata nell'implementazione delle interface causa un errore di compilazione, ovviamente ora non è vero, tant'è che alcuni IDE lo fanno.

Anche perché le interface dubito vengano modificate molto spesso, aggiungere un metodo obbligherebbe ad implementare nuovamente l'interface (tanto vale estendere l'interface) e la cancellazione di un metodo non è praticata di solito, al massimo viene deprecato...

Serve a qualcosa? Tanto per sapere se è sensato usarla o no.

Grazie

[valia]

serve ad indicare che hai una riscrittura del metodo, che nel caso delle interfacce coincide con la prima scrittura.
In generale indica proprio che hai definito altrove la funzione e/o la signature e che li stai andando a darne una nuova definizione.
Qui controlli anche che il tuo metodo è conforme a quello dell'interfaccia (come signature).
Usare la stessa notazione per interfacce/metodi non è una scelta felice, potevi usare qualcosa del tipo @Implements, ma visto che si possono creare gerarchie di classi in cui la padre implementa una interfaccia, la figlia riscrive il comportamento della padre, allora si usa una notazione unica per segnalare la definizione altrove

[yuno]

Che cacchio di domanda! anche io ho notato sta cosa ma non ho trovato nessun motivo apparente per usarla..... la mia rosposta che mi sono dato è: "servirà per alcuni tipi di test che sfruttano le annotazioni" ma è sola una mia spiegazione senza nessun fondamento quindi sto anche io a guardare interessato!

[Kaamos]

Originariamente inviato da valia
serve ad indicare che hai una riscrittura del metodo, che nel caso delle interfacce coincide con la prima scrittura.
In generale indica proprio che hai definito altrove la funzione e/o la signature e che li stai andando a darne una nuova definizione.
Qui controlli anche che il tuo metodo è conforme a quello dell'interfaccia (come signature).
Usare la stessa notazione per interfacce/metodi non è una scelta felice, potevi usare qualcosa del tipo @Implements, ma visto che si possono creare gerarchie di classi in cui la padre implementa una interfaccia, la figlia riscrive il comportamento della padre, allora si usa una notazione unica per segnalare la definizione altrove

Si anche io preferirei un'annotazione dedicata alle interface.

Il ragionamento del controllo della firma del metodo (che è forse il principale motivo per cui hanno scritto quest'annotation) ha senso nell'override dei metodi di una superclasse, ma non in quelli di un'interface perché una signature errata risulterebbe comunque in un errore di compilazione no?

@yuno: si le annotazioni ci sono anche per essere usate insieme alla reflection, ma non penso sia il caso dell'implementazione delle interface... o almeno, non mi viene in mente uno scenario dove fare questo sarebbe utile.

[valia]

esatto, ma in fondo se tu sbagli una signature nell'override di compilare compili, solo che non hai quello che ti interessa.
Vedila a questo livello come un rafforzativo del fatto che una prima definizione è altrove (nell'interfaccia) e che in altri punti ti puoi trovare altre versioni dello stesso metodo

reflection + interfacce: web service!!!
Se tu dichiari un servizio (interfaccia) puoi tramite reflection andare a ritrovare la definizione di funzione, sarà poi il servizio a risolvere il tutto cercando una implementazione

[Kaamos]

Originariamente inviato da valia
esatto, ma in fondo se tu sbagli una signature nell'override di compilare compili, solo che non hai quello che ti interessa.
Vedila a questo livello come un rafforzativo del fatto che una prima definizione è altrove (nell'interfaccia) e che in altri punti ti puoi trovare altre versioni dello stesso metodo

reflection + interfacce: web service!!!
Se tu dichiari un servizio (interfaccia) puoi tramite reflection andare a ritrovare la definizione di funzione, sarà poi il servizio a risolvere il tutto cercando una implementazione

No stavolta non ho capito (la frase in grassetto), se sbaglio la signature del metodo dell'interface non compila, proprio per questo mi sfuggiva l'utilità.

Che per l'override dei metodi della superclasse sia utile siamo tutti d'accordo.

[valia]

no se sbagli in una classe (come extends) di compilare compili, non sono stata chiarissima.

Lo so, è strano, al momento vedila rafforzativo, il web service con reflection è stato un caso d'uso