[JAVA] Method invocation overloading

[Verwijderd]

Ik heb een probleem als ik zelf mijn methodes probeer te invoken dat hij sommige methodes niet kan vinden.

Voorbeeld ik heb een methode:
getSomething(List l)

En die roep ik aan op deze manier:

Java:

instanceMyClass.getClass().getMethod("getSomething", parameter.getClass()).invoke(instanceMyClass, parameter);

Dan gaat het verkeerd omdat mijn parameter van het type Vector is welke dus wel de interface List implementeert.

Verder gaat de aanroep op deze manier ook verkeerd als het om subclasses gaat. Het lijkt er dus op dat deze manier van het aanroepen van een methode niet werkt met method overloading. Heeft iemand enig idee hoe ik dit kan verhelpen?

[Confusion]

getClass() retourneert de runtime class van het object. Als je wilt zoeken naar een passende methode voor een bepaalde parameter, dan zal je de interfaces die de class implementeert stuk voor stuk langs moeten lopen; dan vind je hem wel.

[Robtimus]

Verwijderd schreef op woensdag 08 maart 2006 @ 17:04:
En die roep ik aan op deze manier:

Java:

instanceMyClass.getClass().getMethod("getSomething", parameter.getClass()).invoke(instanceMyClass, parameter);

Wacht eens even, begrijp ik het goed? Je hebt een bekende instance van een bekende class. Je hebt een bekende method met parameterlist. En toch roep je die method aan dmv reflection?
Wat is er mis met gewoon "instanceMyClass.getSomething(parameter)"? (Eventueel met casten)

Of vertel je een deel van het verhaal niet?

[ Voor 5% gewijzigd door Robtimus op 09-03-2006 13:11 ]

[mbravenboer]

Ik neem even aan dat je wel reflection nodig hebt en dat dit alleen een voorbeeldje is om het probleem te illustreren.

Het probleem is dus inderdaad dat je alleen methoden kan vinden als je exact de *gedeclareerde* types van de parameters opgeeft. Als je die types weet, kan je die beter meegeven en dus niet de classes van de actual parameters opvragen.

Als dit echt niet voldoende is, moet er method resolution uitgevoerd worden, wat een erg duur proces is omdat er erg veel methode opgevraagd moet worden, wat stuk voor stuk veel tijd vraagt: het verkrijgen van een Method is erg duur in vergelijking met het uitvoeren van de invocation via reflection. Als je echt precies het gedrag wilt van een methode aanroep in source code, kunnen er allerlei conversies uitgevoerd worden (verzameld onder de noemer method invocation conversions) en moet je checken of de parameters subklassen zijn etc.

Dit wil je in ieder geval niet zelf implementeren. Ik weet niet of er een goede standaard implementatie ergens te krijgen is, maar meestal zitten de meest nuttige uitbreidingen wel bij Jakarta Commons. In dat geval moet je wezen bij de MethodUtils van de Jakarta Commons BeanUtils.

[DaRKie]

reflection moet je zoveel mogelijk vermijden, zoals eerder aangehaald, reflection is duur. In de meeste gevallen kunne reflection oplossingen, aangepast worden in een design met oa interfaces.

Soms is reflection een goede manier van iets op te lossen, maar meestal is het een vorm van bad design

[Verwijderd]

DaRKie schreef op donderdag 09 maart 2006 @ 21:32:
reflection moet je zoveel mogelijk vermijden, zoals eerder aangehaald, reflection is duur. In de meeste gevallen kunne reflection oplossingen, aangepast worden in een design met oa interfaces.

Soms is reflection een goede manier van iets op te lossen, maar meestal is het een vorm van bad design

Oh ok. Ik wist niet dat reflection duur was.

Verder heb ik deze structuur aangehouden omdat het gaat om een server aanroep vanaf de client. Deze komt in een methode terecht die vervolgens checkt welke methode hij daadwerkelijk moet aanroepen. Ik heb het met reflection gedaan omdat ik dacht dat dit sneller is dan zelf een hashmap bijhouden en de juiste methode erbij te zoeken.

Bedankt voor jullie reacties.

[Tubby]

DaRKie schreef op donderdag 09 maart 2006 @ 21:32:
Soms is reflection een goede manier van iets op te lossen, maar meestal is het een vorm van bad design

Ik weet niet of je bekend bent met hibernate. Maar hibernate vetrouwd volledig op reflection, als je bezig bent met een 100% flexibel design kom je vaak niet om reflection heen. Ik ben het met je eens dat reflection vaak onnodig gebruikt wordt, maar om nou te beweren dat het "duur" is (kwa performance neem ik aan) vind ik te ver gaan.

[ Voor 17% gewijzigd door Tubby op 10-03-2006 15:12 ]

[Woy]

Tubby schreef op vrijdag 10 maart 2006 @ 15:10:
[...]
maar om nou te beweren dat het "duur" is (kwa performance neem ik aan) vind ik te ver gaan.

Het is nou eenmaal zo dat het "duur" is. Dat neemt niet weg dat je het niet kan gebruiken maar je moet het niet overal op performance critische plaatsen gaan toepassen.

[JKVA]

rwb schreef op vrijdag 10 maart 2006 @ 15:34:
[...]

Het is nou eenmaal zo dat het "duur" is. Dat neemt niet weg dat je het niet kan gebruiken maar je moet het niet overal op performance critische plaatsen gaan toepassen.

Laat ik een andere reden noemen om ver bij reflection uit de buurt te blijven. Reflection stelt je in staat om encapsulation te omzeilen. Dat is ook precies de reden dat Hibernate het gebruikt, niet zo zeer omdat het flexibeler design toelaat, maar omdat je rechtstreeks properties kunt zetten.

Java:

private static BasicSetter getSetterOrNull(Class theClass, String propertyName) {
               
               if (theClass==Object.class || theClass==null) return null;
               
               Method method = setterMethod(theClass, propertyName);
               
               if (method!=null) {
                       if ( !ReflectHelper.isPublic(theClass, method) ) method.setAccessible(true);
                       return new BasicSetter(theClass, method, propertyName);
               }
               else {
                       BasicSetter setter = getSetterOrNull( theClass.getSuperclass(), propertyName );
                       if (setter==null) {
                               Class[] interfaces = theClass.getInterfaces();
                               for ( int i=0; setter==null && i<interfaces.length; i++ ) {
                                      setter=getSetterOrNull( interfaces[i], propertyName );
                               }
                       }
                       return setter;
               }
               
        }

Deze code staat ergens diep in de core van Hibernate. Als je nu de security iets hoger instelt (zie help van setAccessible) heeft Hibernate mogelijk een groot probleem.

Kortom, blijf eraf.

[.oisyn]

Zie overigens ook [rml][ JAVA] String invoer methode laten activeren[/rml], iemand die precies hetzelfde probeert

[JKVA]

rwb schreef op vrijdag 10 maart 2006 @ 15:34:
[...]

Het is nou eenmaal zo dat het "duur" is. Dat neemt niet weg dat je het niet kan gebruiken maar je moet het niet overal op performance critische plaatsen gaan toepassen.

Overigens, naast het feit dat het zeer lelijke en absoluut niet robuuste code oplevert, hoeft performance geen probleem te zijn, want die methodes kun je gewoon ergens cachen.

[Tubby]

JKVA schreef op vrijdag 10 maart 2006 @ 16:16:
[...]


Laat ik een andere reden noemen om ver bij reflection uit de buurt te blijven. Reflection stelt je in staat om encapsulation te omzeilen. Dat is ook precies de reden dat Hibernate het gebruikt, niet zo zeer omdat het flexibeler design toelaat, maar omdat je rechtstreeks properties kunt zetten.

Java:

private static BasicSetter getSetterOrNull(Class theClass, String propertyName) {
               
               if (theClass==Object.class || theClass==null) return null;
               
               Method method = setterMethod(theClass, propertyName);
               
               if (method!=null) {
                       if ( !ReflectHelper.isPublic(theClass, method) ) method.setAccessible(true);
                       return new BasicSetter(theClass, method, propertyName);
               }
               else {
                       BasicSetter setter = getSetterOrNull( theClass.getSuperclass(), propertyName );
                       if (setter==null) {
                               Class[] interfaces = theClass.getInterfaces();
                               for ( int i=0; setter==null && i<interfaces.length; i++ ) {
                                      setter=getSetterOrNull( interfaces[i], propertyName );
                               }
                       }
                       return setter;
               }
               
        }

Deze code staat ergens diep in de core van Hibernate. Als je nu de security iets hoger instelt (zie help van setAccessible) heeft Hibernate mogelijk een groot probleem.

Kortom, blijf eraf.

Deze code doet weinig meer dan via de getSetterOrNull een Method object terug halen uit de class of zijn interfaces, dat is iets heel anders als de properties direct setten. Sterker nog, als je classes maakt zonder getters en setters krijg je foutmeldingen van hibernate omdat hibernate de getters en setters nodig heeft om de properties te kunnen setten.

[JKVA]

Dat klopt, en dat is ook precies wat ik ermee probeerde te zeggen, namelijk dat je niet echt robuuste applicaties krijgt op deze manier. Ik beweer niet dat Hibernate nooit aan die properties kan komen, maar dat het afhankelijk is van de VM en dat wil je bij voorbaat niet. (tenminste ik niet)

[Robtimus]

Verwijderd schreef op vrijdag 10 maart 2006 @ 14:22:
[...]


Oh ok. Ik wist niet dat reflection duur was.

Verder heb ik deze structuur aangehouden omdat het gaat om een server aanroep vanaf de client. Deze komt in een methode terecht die vervolgens checkt welke methode hij daadwerkelijk moet aanroepen. Ik heb het met reflection gedaan omdat ik dacht dat dit sneller is dan zelf een hashmap bijhouden en de juiste methode erbij te zoeken.

Bedankt voor jullie reacties.

Is RMI geen optie? Dan kun je transparant gewoon de methodes aanroepen die je nodig hebt. Je gebruikt de server alsof deze een local object is. De rest doet de JVM voor je op de achtergrond.