[java] - interfaccia per metodi di cui non si conosce il nome

[citrus]

salve a tutti,
sto realizzando un applicativo che potrà essere espanso aggiungendo dei metodi
il cui nome verrà salvato in una base dati e che verranno richiamati dinamicamente
tramite l'uso delle api reflection.
tutti i metodi che verranno però aggiunti devono avere in ingresso gli stessi identici
parametri..
ho scritto una classe contenitore dove potranno essere implementati tutti i metodi aggiuntivi ma non so come obbligare l'utente a definire i nuovi metodi con gli stessi parametri degli altri...
pensavo di scrivere un interfaccia ma per definire il prototipo di un metodo bisogna
conoscerne il nome... mentre io il nome non lo posso conoscere....

ecco dunque la mia domanda....
è possibile definire un interfaccia che imponga solo il tipo di ritorno e il tipo di dati in ingresso ma senza specificare il nome dei metodi?

spero che saprete aiutarmi
grazie a tutti
citruz

[ivenuti]

non penso tu possa imporre questo vincolo. Al più potresti, quando scorri i nomi dei metodi, verificare i parametri e dare degli errori al runtime se non rispettano la signature imposta.

Domanda scema: se fissi i parametri (e qui mi pare una "imposizione" piuttosto dura), perché mai lasci libero il nome del metodo?? che si chiami pippo o pluto, che ti cambia?

ciao

[citrus]

Originariamente inviato da ivenuti
non penso tu possa imporre questo vincolo. Al più potresti, quando scorri i nomi dei metodi, verificare i parametri e dare degli errori al runtime se non rispettano la signature imposta.

Domanda scema: se fissi i parametri (e qui mi pare una "imposizione" piuttosto dura), perché mai lasci libero il nome del metodo?? che si chiami pippo o pluto, che ti cambia?

ciao

si potrei fare un controllo a runtime come dici tu...

il nome del metodo deve essere libero perchè l'utente li aggiungerà liberamente in futuro
ed io ovviamente non posso sapere quali nome gli darà...

l'imposizione sui parametri invece è necessaria perchè questi metodi vengono richiamati
dinamicamente all'interno di un programma che, per funzinonare, deve passargli determinati oggetti e ricavarne obbligatoriamente un booleano...

grazie

[andbin]

Originariamente inviato da citrus
è possibile definire un interfaccia che imponga solo il tipo di ritorno e il tipo di dati in ingresso ma senza specificare il nome dei metodi?

No, ma lo fai già tu, in un certo senso, quando usi la reflection. Devi usare il metodo getMethod di Class:

Method getMethod(String name, Class<?>... parameterTypes)

è chiaro che dato il nome di un metodo e un elenco di Class per definire i parametri (che imponi tu), il metodo .... o c'è o non c'è. Se c'è, bene hai un oggetto Method, se non c'è ti becchi NoSuchMethodException.

Il valore di ritorno non fa parte della "signature" di un metodo. Puoi verificare cosa ritorna usando getReturnType() di Method.

[citrus]

Originariamente inviato da andbin
No, ma lo fai già tu, in un certo senso, quando usi la reflection. Devi usare il metodo getMethod di Class:

Method getMethod(String name, Class<?>... parameterTypes)

è chiaro che dato il nome di un metodo e un elenco di Class per definire i parametri (che imponi tu), il metodo .... o c'è o non c'è. Se c'è, bene hai un oggetto Method, se non c'è ti becchi NoSuchMethodException.

Il valore di ritorno non fa parte della "signature" di un metodo. Puoi verificare cosa ritorna usando getReturnType() di Method.

infatti è proprio quello che intendevo...
se richiamo il metodo con la reflection e il metodo non è formato correttamente non viene trovato e quindi nemmeno invocato...
la mia paura non è tanto che vengano passati i parametri errati, ma che a causa di ciò il metodo non venga trovato...
quindi per costringere il cliente a implementare i metodi correttamente avrei bisogno un meccanismo tipo le interfaccie.. ma un po' più flessibile...
così che il compilatore gli ritorni un errore da subito...
altrimenti il cliente potrebbe passare giornate intere a domandarsi perchè il suo metodo non viene eseguito...
cmq non è così indispensabile...
posso sempre intercettare l'eccezione e bloccare il programma, non è bellissimo ma almeno fa capire al cliente che qualcosa non va...

[andbin]

Originariamente inviato da citrus
quindi per costringere il cliente a implementare i metodi correttamente avrei bisogno un meccanismo tipo le interfaccie.. ma un po' più flessibile...

Non c'è.
L'unico vincolo formale, a livello del linguaggio, è dato dalle interfacce (o dalle classi astratte) ma in ogni caso la signature del metodo (nome+parametri) è chiaramente vincolata.

Dovresti spiegare meglio perché hai bisogno di fare una cosa del genere .... cioè quale è la necessità reale?

[citrus]

sto creando un batch per l'importazione delle bolle/colli in un sistema...
il problema è che ogni cliente ha le sue scimmie quindi invece che creare un batch
nuovo ogni volta che si deve lavorare con un nuovo cliente abbiamo deciso di creare una
procedura standard "alterabile" a runtime richamando metodi, query, regole di validazione sui dati ecc... che vengono tutte salvate in una base dati e richiamate dinamicamente...

la cosa sembra funzionare molto bene ma ho qualche problema con il richiamo di metodi java
proprio per il motivo che ti spigavo...
cmq un po' per volta sto risolvendo...
in questo caso ad esempio solleverò un eccezione bloccante...
la bolla infatti verrà scartata perchè la regola non è applicabile...
d'altronde se non c'è altro modo...

[andbin]

Originariamente inviato da citrus
sto creando un batch per l'importazione delle bolle/colli in un sistema...
il problema è che ogni cliente ha le sue scimmie quindi invece che creare un batch
nuovo ogni volta che si deve lavorare con un nuovo cliente abbiamo deciso di creare una
procedura standard "alterabile" a runtime richamando metodi, query, regole di validazione sui dati ecc... che vengono tutte salvate in una base dati e richiamate dinamicamente...

Allora puoi farlo proprio con una classe astratta.

Crei una classe astratta OperazioniCliente che definisce dei metodi astratti relativi ai vari compiti che si debbono fare. A questo punto sei costretto a estendere la classe se vuoi fare le operazioni per un tal cliente. Quindi crei: OperazioniPippo, OperazioniPluto ecc... in cui fai delle cose specifiche per ognuno dei clienti.

[citrus]

mmm no non deve funzionare così...
i metodi potrebbero essere nMila e io no ndevo conoscerne il nome...
perchè verranno inseriti negli anni a venire e io non sono un oracolo haimè

mi sa che l'alternativa è lasciare al cliente di fare quello che vuole e poi spruzzare un errore se non fa quello che dico io