Guida interfacce, parametri e tipi di ritorno

[z3n]

Ciao a tutti,
spero di non ripetere l'argomento ma dopo aver cercato nel forum (e in google) non ho trovato quello che cercavo:
ho bisogno di una guida avanzata sulle interfacce Java, i tipi di ritorno (delle interfacce e delle classi che le implementano) e i parametri in ingresso (delle interfacce e delle classi che le implementano).
Avete qualcosa da consigliarmi?
Grazie

[andbin]

Originariamente inviato da z3n
spero di non ripetere l'argomento ma dopo aver cercato nel forum (e in google) non ho trovato quello che cercavo:
ho bisogno di una guida avanzata sulle interfacce Java, i tipi di ritorno (delle interfacce e delle classi che le implementano) e i parametri in ingresso (delle interfacce e delle classi che le implementano).

Per "interfacce" intendi le interface definibili in Java?
Allora non c'è nulla di "avanzato" da sapere. Se sai cosa sono le classi e anche cosa sono le classi astratte allora dovresti anche sapere (o perlomeno averne una buona idea) cosa è una interfaccia.

[z3n]

so cosa sono le interfacce, ma ho dei dubbi circa l'uso...
nello specifico, provo a spiegarmi con un esempio...
ho un'interfaccia IMaker che definisce le azioni base, e una classe Maker che esegue quelle specifiche azioni in un particolare contesto.
poi ho un'alta IOrganizer che defisce particolari metodi, e una classe Organizer che implementa quei metodi un particolare contesto (lo stesso di Maker).
Ora, se io volessi cambiare contesto, dovrei teoricamente re-implementare le classi Maker e Organizer (ovviamente sempre implementando le medesime interfacce. supponiamo che l'interfaccia IMaker abbia un metodo:

public IMaker doThis(IMaker);

e ovviamente la classe Maker implementi lo stesso metodo:

public IMaker doThis(IMaker im){
	Maker m=new Maker();
	m.metodo();
        im=m;
	......
	return m;
	}

quello di cui non sono sicuro è il tipo di ritorno nel metodo implementato (IMaker oppure Maker)? e stessa domanda per il parametro im IMaker (IMaker o Maker)?

[andbin]

Originariamente inviato da z3n
quello di cui non sono sicuro è il tipo di ritorno nel metodo implementato (IMaker oppure Maker)? e stessa domanda per il parametro im IMaker (IMaker o Maker)?

Quando implementi un metodo di una interfaccia, devi seguire le regole che valgono in generale quando si fa un "override".

Il parametro deve essere IMaker, se fosse Maker faresti un "overload" (non staresti implementando il metodo e non ti compilerebbe!) e non un override.
Prima di Java 5 il tipo di ritorno doveva essere tassativamente uguale. A partire da Java 5 è stato introdotto il concetto di "tipo di ritorno covariante" (o più brevemente "return covariante"). Ovvero il metodo che fa l'override può dichiarare un tipo di ritorno che è un sottotipo del tipo di ritorno del metodo nella interfaccia/superclasse di cui sta facendo l'override (chiaramente non vale per tipi primitivi!).
Quindi da Java 5, nella tua classe Maker il doThis può tecnicamente e legalmente dichiarare come tipo di ritorno sia IMaker, sia Maker.

Se metti IMaker stai ad un livello più astratto, se metti Maker dai una informazione in più ad un eventuale chiamante che invoca doThis su un reference di tipo Maker (se lo fa su un IMaker, "vede" solo il doThis che ritorna IMaker), che potrebbe essere utile se magari Maker "offre" qualcosa di più (es. metodi aggiuntivi).

[z3n]

Ti ringrazio moltissimo per la spiegazione, sei stato davvero preciso ed esauriente! Credo di aver capito tutto ora, non credo ci sia altro da sapere sulle interfacce!
Grazie ancora!

[z3n]

Ciao,
ho un altro piccolo dubbio in merito alla stessa questione:
visto che il tipo di parametro in ingresso in un metodo della classe Maker deve essere lo stesso dell'interfaccia IMaker, per non essere dipendente dal tipo (Maker in questo caso) ma poter utilizzare una qualsiasi classe che implementa IMaker, ho pensato di fare così:

public IMaker doThis(IMaker im){
	Maker m=im;
	m.metodo();
	......
	return m;
	}

così io posso sosituire Maker con qualsiasi oggetto di una classe che implementa IMaker. Che ne pensi?

[andbin]

Originariamente inviato da z3n
visto che il tipo di parametro in ingresso in un metodo della classe Maker deve essere lo stesso dell'interfaccia IMaker, per non essere dipendente dal tipo (Maker in questo caso) ma poter utilizzare una qualsiasi classe che implementa IMaker, ho pensato di fare così:

public IMaker doThis(IMaker im){
	Maker m=im;
	m.metodo();
	......
	return m;
	}

così io posso sosituire Maker con qualsiasi oggetto di una classe che implementa IMaker. Che ne pensi?

Io ovviamente non so che concetto/logica deve implementare quel doThis (e in generale che cosa deve rappresentare un IMaker).
Se fai come hai appena scritto, non crei/hai nuovi oggetti. Quello che fai, lo fai sull'oggetto passato al doThis. In base a cosa fai sull'oggetto (es. cosa fa concretamente quel metodo() ), potresti potenzialmente andare a cambiare lo "stato" dell'oggetto passato.
È questo che volevi fare? Fare qualcosa con l'oggetto e/o cambiargli lo stato? Se è così, ok. Se non è così, hai sbagliato concetto.

Consiglio: tralascia un pochino le questioni "tecniche" sui parametri e valuta bene: che cosa rappresenta e deve fare in generale un (qualunque) IMaker?

[z3n]

Se ho capito cosa intendi si, è questo che volevo fare, ma provo a spiegarti meglio (IMaker e Maker ecc sono classi inventate per spiegarmi perchè non posso per ora rivelare nulla di specifico, ma per aggiungere dettagli importanti devo aggiungere un'altra classe):

diciamo che Maker è un'implementazione che permette di interagire con una determinata tecnologia.
Poi ho un'altra interfaccia IManage e la sua implementazione Manage (che utilizza oggetti Maker) per interagire direttamente.
Quello che voglio fare, è creare un metodo di in IManage, che dato in ingresso un oggetto IMaker (seguendo il mio ragionamento di prima) esegue determinate operazioni.
Il punto è che devo poter sostituire Maker con un'altra implementazione di IMaker per utilizzare un'altra tecnologia, ma se ammettiamo un metodo di IManage ha come parametro in ingresso un oggetto di tipo Maker, in un'altra implementazione di IManager il parametro dovrà essere sempre Maker, e non potrà essere di un'altra implementazione di IMaker.
Forse questo esempio di metodi chiarisce il tutto:

public interface IManage {

	public void inteact(IMaker);
}

public class Manage implements IManage{
	
	public void interact(IMaker im){
		Maker m=im;
		m.eseguiAzione1();
		m.eseguiAzione2();
	
	}
}

ora se io a questo punto vorrei creare un'altra implementazione di IManage per utilizzare un'altra tecnologia, potrei creare un'altra implementazione di IMaker specifica e sarei aposto. il mio dubbio riguarda il punto in grassetto:

public class Manage implements IManage{

public void interact( IMaker im){

Maker m=im;

m.eseguiAzione1();
m.eseguiAzione2();

}

spero di essere stato chiaro nella spiegazione, e mi scuso se ho incasinato un po' le cose...

[andbin]

Originariamente inviato da z3n

	public void interact( IMaker  im){
                
		Maker m=im;
                

Quello che hai fatto (scritto in grassetto) è concettualmente un "down-cast" e tecnicamente va fatto con un cast esplicito. La riga in grassetto non ti compilerebbe nemmeno!

Anche ammesso di fare correttamente:

Maker m = (Maker) im;

resterebbe comunque un fatto: interact funzionerebbe solo se gli passi un Maker ... non un MakerB, MakerC ecc... (altre implementazioni di IMaker, insomma).
Quindi? Che senso avrebbe? Per dirla in altro modo: perché interact dovrebbe essere "legata" ad una implementazione specifica piuttosto che ad una astrazione più generica?

[z3n]

Originariamente inviato da andbin

resterebbe comunque un fatto: interact funzionerebbe solo se gli passi un Maker ... non un MakerB, MakerC ecc... (altre implementazioni di IMaker, insomma).
Quindi? Che senso avrebbe? Per dirla in altro modo: perché interact dovrebbe essere "legata" ad una implementazione specifica piuttosto che ad una astrazione più generica?

é proprio quello il mio problema: non voglio legare metodi come interact ad una particolare implementazione di IMaker, ma voglio far sì che accetti qualsiasi implementazione di IMaker, ed è quello che ho cercato di fare, o almeno l'intenzione era quella.
Come potrei fare?