[JAVA] Dynamisch casten via Reflectie

[GrooV]

Ik ben bezig met een client server project, als de client een request doet aan de server dan krijgt hij een RemoteObject terug welke een inner object van het type Object en een String met het type Object.

Nu wil ik dat de client het inner object kan casten naar het type object in de string. Nu kan ik wel via reflectie een klasse maken van het type maar dan heb ik nogsteeds een Class object een niet het object wat ik graag wil

Pseudo Code:

code:

RemoteObject roObj = (RemoteObject) tmpObj;
Class klasse = Class.forName(roObj.getInnerType());
klasse inObj = (klasse) roObj.getInnerObject();

De Class klasse heeft wel een Cast methode maar als ik mijn Object als parameter mee geef dan cast hij het nogsteeds naar een Object.

Heeft iemand enig idee hoe ik dit kan oplossen? De objecten zijn trouwens aan beide kanten aanwezig dus het is niet zo dat de client niet dezelfde klassen als de server heeft

[Robtimus]

Kun je niet beter met interfaces gaan werken? Dan kun je gewoon casten naar de interface, en de daadwerkelijke class boeit dan niet.

[GrooV]

IceManX schreef op donderdag 25 september 2008 @ 20:23:
Kun je niet beter met interfaces gaan werken? Dan kun je gewoon casten naar de interface, en de daadwerkelijke class boeit dan niet.

Ok maar dan is het niet mogelijk om iets generieks te maken met bijvoorbeeld verschillende interfaces. Of kan je de interfaces wel dynamisch inladen?

[kw4h]

Is het de bedoeling dat je dat Object, cast naar het type dat staat in de String, zodat je daar de specifieke methodes op kan aanroepen?
Als dat zo is, vraag ik me af of dat wel mogelijk is. Zoiets (casten naar een type om daarna specifieke methodes aan te roepen) is niet mogelijk via dynamisch casten. Oftewel, ergens in je code moet je dat toch hard gaan neerzetten.

Met een Interface, zoals IceManX beschreef, kan je wel dynamisch casten aangezien de invulling van de methode in het object zit. Zolang het object dus die Interface implementeert kan je hem aanroepen alszijnde die Interface. (nogwat Polymorphie heet dat)

[GrooV]

kw4h schreef op donderdag 25 september 2008 @ 21:53:
Is het de bedoeling dat je dat Object, cast naar het type dat staat in de String, zodat je daar de specifieke methodes op kan aanroepen?
Als dat zo is, vraag ik me af of dat wel mogelijk is. Zoiets (casten naar een type om daarna specifieke methodes aan te roepen) is niet mogelijk via dynamisch casten. Oftewel, ergens in je code moet je dat toch hard gaan neerzetten.

Met een Interface, zoals IceManX beschreef, kan je wel dynamisch casten aangezien de invulling van de methode in het object zit. Zolang het object dus die Interface implementeert kan je hem aanroepen alszijnde die Interface. (nogwat Polymorphie heet dat)

Dat is inderdaad de bedoeling, ik denk dat ook ga gebruiken. Het is de bedoeling dat deze laag de data ophaalt voor de rest van het programma. Ik hoopte dat ik het allemaal zo generiek mogelijk kon houden maar nu zal ik toch het een en ander vast moeten zetten.

[NetForce1]

Om zonder reflection methodes op een object aan te roepen zul je toch van te voren al moeten weten wat het type is van het object. Je kunt dus niet een klasse laden via reflection, een object daar naar casten, en dan methodes aanroepen op dat object. De compiler weet immers niet naar welk type je cast.
Je moet dus interfaces maken die je objecten implementeren of, als het nog generieker moet, de methodes via reflection aanroepen maar dat is niet fijn voor leesbaarheid en onderhoudbaarheid van je code.

[tweakerbee]

Als je weet wat voor Object je gaat krijgen kun je gewoon rechtstreeks casten. Als je het niet weet... dan kun je ook niet casten (wat NetForce1 zegt).

[Confusion]

GrooV schreef op donderdag 25 september 2008 @ 22:15:
Dat is inderdaad de bedoeling, ik denk dat ook ga gebruiken. Het is de bedoeling dat deze laag de data ophaalt voor de rest van het programma. Ik hoopte dat ik het allemaal zo generiek mogelijk kon houden maar nu zal ik toch het een en ander vast moeten zetten.

Als je het zo generiek mogelijk wilt houden, dan moet je zorgen dat je client een brok Java ophaalt, dat runtime compileert en de code die eruit ontstaat aanzwengelt. Generieker dan dat wordt het niet.

[MSalters]

KLinkt dom, maar uiteindelijk is het wel nodig. Als de server het type FooBar2009 stuurt, hoe komt de client dan aan de bytecode daarvoor?

[Ruudjah]

Als je het zo generiek mogelijk wilt houden, dan moet je zorgen dat je client een brok Java ophaalt, dat runtime compileert en de code die eruit ontstaat aanzwengelt. Generieker dan dat wordt het niet.

Wat dacht je van een complete VM, JIT compiler en intermediate code interpreter erbij?

[roy-t]

Als de code aan beide kanten die classes heeft kun je dan niet beter switchen op die string en dan vanaf daar casten en verder gaan? Dit zou immers wel moeten kunnen met java.

[GrooV]

roy-t schreef op zaterdag 11 oktober 2008 @ 20:07:
Als de code aan beide kanten die classes heeft kun je dan niet beter switchen op die string en dan vanaf daar casten en verder gaan? Dit zou immers wel moeten kunnen met java.

Ik heb het nu ook opgelost dmv het switchen op string en daarna te casten

[Confusion]

Welk probleem probeer je eigenlijk op te lossen?

[Woy]

Sowieso heeft het geen nut om te casten naar een type wat je compile time nog niet weet. Casten veranderd het type namenlijk niet, het veranderd alleen de informatie die de compiler over het type heeft.

Als je compile time toch nog niet weet welk type het is heb je er dus ook niks aan om er naar te casten, want je hebt er geen extra informatie over.

Of probeer je iets als late binding voor elkaar te krijgen?

[Kettrick]

Confusion schreef op dinsdag 14 oktober 2008 @ 20:52:
Welk probleem probeer je eigenlijk op te lossen?

Ik gok op het niet precies weten *wat* er heen en weer gegooid gaat worden, iets waar ik vaak kriebels van krijg

zorg voor een duidelijke interface tussen de client en server, dat maakt het allemaal een stuk makkelijker en, hoewel minder "generiek", meestal beter geschikt voor de toekomst.