Annoso problema delle interfacce

[GoldEmish]

Ciao a tutti,
vorrei sapere la vostra opinione riguardo all'uso delle interfacce in Java.

Lavorando con applicazioni Web su JEE ho visto molto spesso che tutti i servizi hanno un'interfaccia e la classe di implementazione.
es. ServiceTest.java(interface) e ServiceTestImpl.java

Non capisco il senso di questa cosa, visto che stiamo parlando di servizi interni all'applicazioni e non di EJB o simili che vantaggi ha questa cosa?

Grazie, ciao!

[antotan]

Probabilmente per utilizzare il polimorfismo. O in previsione di chiamate remote (chissà, domani potrebbero servire). Dipende, è un pò vago così.

[valia]

In questo caso la logica principale è separare la dichiarazione di intenti dall'implementazione: l'interfaccia spesso serve a dire al mondo intero COSA fai, non c'è bisogno che il mondo intero sappia COME lo fai. Spesso usi appunto l'interfaccia per creare i documenti che mandi al mondo esterno (hai presente quello che succedeva inizialmente con i web service e il wsdl? oggi si possono usare anche le annotation per creare il wsdl, ma inizialmente il wsld partiva dall'interfaccia del servizio)

L'interfaccia inoltre è un ottimo metodo per ottenere l'ereditarietà multipla in java (cosa impossibile estendendo la classe).

[GoldEmish]

Beh, capisco le vostre interpretazioni, ma io sto parlando di servizi interni all'applicazione. In questo caso mi capita spesso di vedere dentro lo stesso package l'interfaccia e affianco l'implementazione.
In questo caso a me pare inutile, perchè volendo estendere l'interfaccia posso sempre usare l'implementazione, inoltre la sorgente sarà sempre pubblica all sviluppatore visto che parlo di servizi interni. Può essere che sia solo per l'ereditarietà multipla?!?

La cosa è molto diffusa, parlo in particolare di applicazioni web con Spring... ci sarà un buon motivo!

Grazie

[oronze]

ecco, già che ci sono anche io sarei curioso di capire sta cosa...dato che un interfaccia fornisce solo delle regole per sviluppare la classe che la implementa, come si può parlare di erediarietà multipla dato che in ogni caso mi devo implementare io i miei metodi?

public interfacce Uomo{
public pensa();
public haMani();
}
public interfacce Toro{
public corre();
public haMuscoli();
}
public interfacce Cavallo{
public nitrisce();
public ha4Zampe();
}
public class Minotauro implements Uomo, Toro{
...
}
public class Centauro implements Uomo, Cavallo{
...
}

L'unico motivo per il quale scriverei un codice del genere è nel caso dovessi far utilizzare la classe a qualcuno che non sà cos'è un Minotauro e un Centauro. In questo caso fornirei le interfacce in modo da specificare quali sono i metodi (caratteristiche) che essi devono avere. Nel caso il programma lo utilizzi solo io non mi conviene evitare di scrivere le interfacce? Sta storia delle interfacce non mi ha mai convinto. Teoricamente sono ok ma praticamente nn ho ancora capito il loro posto in Java
Grazie!

[valia]

vieni da programmazione procedurale??
Quante volte hai visto negli header solo il prototipo della funzione e poi lo hai implementato in altri file? Questa è una prima forma di definizione di interfaccia: una dichiarazione di intenti. Tu dichiari cosa fa il metodo, non come lo fa.
Pensa alla classe ArrayList: implementa list che a sua volta estende Collection. Tu sai che la tua lista deve consentirti add, remove, bene lo dichiari nell'interfaccia. Volendo runtime tu puoi fare una roba del genere

List lista = new Arraylist(); 
List lis = new MyArrayList();

e puoi usare questi due oggetti come useresti un oggetto List (quindi su questi fai add, remove ecc) ma non ti frega niente dell'implementazione che usi, perché cmq sai che quelle operazioni le puoi fare. Questa è già una bella potenza, ma come ti dicevo non salta subito all'occhio se non ti trovi a lavorare su ste cose.

L'utilità in piccolo: tu pensa a sviluppare un programma di grosse dimensioni, devi fare un piano (scritto) di cosa farai, delle funzioni che ti servono ecc. Ma il piano ad alto livello come lo fai? interfacce (o qualcosa che somiglia): dici a grandi linee cosa fare, sarà poi l'utente a farlo.

Per quanto riguarda l'ereditarietà multipla: non mi viene un esempio pratico, non ricordo manco dove ho buttato gli appunti.
Mi viene da pensare ad una roba che ho fatto:
componente JXDatePicker (per la data). Volevo farne una mia versione (l'ho inserito in un pannello che avesse anche altre proprietà), ma volevo che fosse anche validabile secondo le mie regole.

Quindi ho la classe Validatore (che impone le regole di validazione), il mio componente e visto che in java

class MyDatePicker extends JXDatePicker, Validator

è vietato ci ho girato intorno dicendo che Validator è un'interfaccia.

class MyDatePicker extends JXDatePicker implements Validator, Cloneable

e ci ho aggiunto Cloneable per farti capire che di interfacce puoi metterne quante vuoi.

Tu dici ma in quel modo devo implementarmi il metodo. Nel 90% dei casi l'ereditarietà equivale ad override di qualche metodo. Se scrivi bene la struttura, ti troveresti cmq a fare solo l'override di quel metodo, che differenza c'è a quel punto per te implementarlo o farne l'override?

Se vuoi cmq una versione di default crea la tua classe implementazione default che userai nei casi in cui l'ereditarietà multipla non serve.

In progetti di piccole dimensioni cmq è difficile vedere queste cose

[valia]

Originariamente inviato da GoldEmish
Beh, capisco le vostre interpretazioni, ma io sto parlando di servizi interni all'applicazione. In questo caso mi capita spesso di vedere dentro lo stesso package l'interfaccia e affianco l'implementazione.
In questo caso a me pare inutile, perchè volendo estendere l'interfaccia posso sempre usare l'implementazione, inoltre la sorgente sarà sempre pubblica all sviluppatore visto che parlo di servizi interni. Può essere che sia solo per l'ereditarietà multipla?!?

La cosa è molto diffusa, parlo in particolare di applicazioni web con Spring... ci sarà un buon motivo!

Grazie

In realtà una buona organizzazione vorrebbe da un lato l'interfaccia (package interfaces) e dall'altro l'implementazione. Interfaces in genere è quello che esponi in rete, la logica è quella.
Mai fatto web service senza annotation?

[GoldEmish]

Piano un attimo, CTRL-ALT-CANC.

Sull'ereditarietà sono d'accordo, anche per servizi da esporre all'esterno!
Un esempio pratico è una lista di elementi univoci, potrebbe essere:

public class UniqueList implements List, Set

perchè è una lista, ma non ammette duplicati

Però, nel caso di web app dove esitono servizi "interni" tipo LoginService che contine tutti i metodo e i componenti per la login, DaoService per accesso al db ecc.
Tutto queste sono classi che io userò solamente nella mia applicazione, nel caso volessi poi esporle dovrei in ogni caso creare le classi apposta per l'EJB.
In questo caso... perchè tutti i servizi (es. LoginService) vanno sempre in coppia con le interfacce?

public interface LoginService{
   public boolean login(String user,String password);
   public boolean logout();
}

public class LoginServiceImpl implements LoginSerice{
...
}

[oronze]

Originariamente inviato da valia
vieni da programmazione procedurale??
Quante volte hai visto negli header solo il prototipo della funzione e poi lo hai implementato in altri file? Questa è una prima forma di definizione di interfaccia: una dichiarazione di intenti. Tu dichiari cosa fa il metodo, non come lo fa.
Pensa alla classe ArrayList: implementa list che a sua volta estende Collection. Tu sai che la tua lista deve consentirti add, remove, bene lo dichiari nell'interfaccia. Volendo runtime tu puoi fare una roba del genere

List lista = new Arraylist(); 
List lis = new MyArrayList();

e puoi usare questi due oggetti come useresti un oggetto List (quindi su questi fai add, remove ecc) ma non ti frega niente dell'implementazione che usi, perché cmq sai che quelle operazioni le puoi fare. Questa è già una bella potenza, ma come ti dicevo non salta subito all'occhio se non ti trovi a lavorare su ste cose.

L'utilità in piccolo: tu pensa a sviluppare un programma di grosse dimensioni, devi fare un piano (scritto) di cosa farai, delle funzioni che ti servono ecc. Ma il piano ad alto livello come lo fai? interfacce (o qualcosa che somiglia): dici a grandi linee cosa fare, sarà poi l'utente a farlo.

Per quanto riguarda l'ereditarietà multipla: non mi viene un esempio pratico, non ricordo manco dove ho buttato gli appunti.
Mi viene da pensare ad una roba che ho fatto:
componente JXDatePicker (per la data). Volevo farne una mia versione (l'ho inserito in un pannello che avesse anche altre proprietà), ma volevo che fosse anche validabile secondo le mie regole.

Quindi ho la classe Validatore (che impone le regole di validazione), il mio componente e visto che in java

class MyDatePicker extends JXDatePicker, Validator

è vietato ci ho girato intorno dicendo che Validator è un'interfaccia.

class MyDatePicker extends JXDatePicker implements Validator, Cloneable

e ci ho aggiunto Cloneable per farti capire che di interfacce puoi metterne quante vuoi.

Tu dici ma in quel modo devo implementarmi il metodo. Nel 90% dei casi l'ereditarietà equivale ad override di qualche metodo. Se scrivi bene la struttura, ti troveresti cmq a fare solo l'override di quel metodo, che differenza c'è a quel punto per te implementarlo o farne l'override?

Se vuoi cmq una versione di default crea la tua classe implementazione default che userai nei casi in cui l'ereditarietà multipla non serve.

In progetti di piccole dimensioni cmq è difficile vedere queste cose

non vengo dalla programmazione procedurale...sono uno studente e sto studiando Java, sono partito da JS e PHP ma anche in quei due linguaggi programmavo ad oggetti...in ogni caso non mi è ancora ben chiaro il fatto delle interfacce...se mi creo la mia struttura dati sò già che metodi mi serviranno...perchè usare un'interfaccia? Tornando al tuo esempio... class MyDatePicker extends JXDatePicker implements Validator
dato che Validator è una interfaccia che hai creato tu, perchè non hai semplicemente fatto MyDatePicker extends JXDatePicker e dentro definivi i metodi di validator? senza crearti l'interfaccia e poi definirli?

[satifal]

Originariamente inviato da GoldEmish
...
La cosa è molto diffusa, parlo in particolare di applicazioni web con Spring... ci sarà un buon motivo!

Grazie

Uno dei tantissimi pattern implementati da Spring è l'IoC (Inversion of Control) tramite il quale è possibile mantenere disaccoppiati i singoli componenti di un sistema. Utilizzando tale pattern le dipendenze non vengono scritte nel codice del componente ma gli vengono iniettate dall'esterno. Per l'attuabilità di tale meccanismo è assolutamente necessario l'utilizzo delle interfacce. In pratica, all'interno del codice si ragiona per interfacce, mentre dall'esterno tramite file di configurazione XML vengono iniettate nel codice le implementazioni di tali interfacce, le quali, possono facilmente essere sostituite in base alle esigenze semplicemente modificando il file di configurazione. Si tratta di un pattern relativamente nuovo ed assolutamente innovativo.