[JAVA] Dynamisch objecten aanroepen

[Verwijderd]

Ik heb al aardig er oplos gegoogled maar ik kan helaas het antwoord op de volgende vraag niet vinden: Hoe kan je in java dynamisch objecten aanroepen?

Bijvoorbeeld:

code:

public void reinitialize(String vakje) {

theSpelUI.vakje.getNaam();

}

Hierbij moet vakje in de call "theSpelUI.vakje.getNaam();" dus vervangen worden door de String vakje die meegegeven word als argument als de methode reinitialize aangeroepen word.

Een oplossing is natuurlijk om alle vakje objecten in een vector of array te stoppen zodat je vakje[2] ofzo kunt zeggen. Maar volgens mij moet er een makkelijkere manier zijn die ik over het hoofd zie

[zwippie]

* zwippie probeert ook eens wat:
Kun je van de parameter 'String vakje' ook 'Object vakje' maken? Zoals:

Java:

public void reinitialize(Object vakje) {

theSpelUI.vakje.getNaam();

}

Het is niet precies wat je bedoelt geloof ik, maar ik kon de functie waar je naar op zoek bent ook niet vinden.

[Verwijderd]

Dat is helaas niet mogelijk, reinitialize word aangeroepen door een eventHandler die alleen maar over de naam van het object beschikt en niet over het gehele object .

Bedankt voor de input anyway

[Verwijderd]

met FindClassByName de class ophalen en die gebruiken?

[Verwijderd]

je kan een object initialiseren dynamisch in java door reflection te gebruiken.
String klassenaam;
Class class = Class.forName(klassenaam);
Object o = class.newInstance();

[bigbeng]

Ik weet niet precies hoe je datgene moet doen wat je wilt, maar het principe waar je het over hebt heet reflection. Daarmee kun je weer even gaan googlen.

[.oisyn]

Een cursus programmeren is misschien wel handig?

Strings zijn gewone objecten, ze vormen geen textuele substitutie voor je programma. Je zou het met reflection kunnen doen, maar beter gebruik je gewoon een geassocieerde structuur zoals bijvoorbeeld een hashmap, om het juiste object bij de juiste string te vinden.

[Verwijderd]

.oisyn schreef op 04 mei 2004 @ 15:10:
Een cursus programmeren is misschien wel handig?

What do you think im doing? Is alweer 3 jaar geleden voor me dat ik wat met Java gedaan heb

Dan zal het er waarschijlijk op uitdraaien dat ik alle objecten in een vector of array plaats. Of een array met verwijzingen naar de objecten om ze te mappen zoals jij zei.

[DaCoTa]

Het lijkt erop dat je een mapping wil van String vakje naar String naam. Als je vooraf alle vakje - naam paren in een HashMap gooit, kun je ze er zo weer uit pielen met hashMap.get(vakje).toString();

Over reflection: als je een oplossing wilt verzinnen waar reflection bij komt kijken, heb je in 99 van de 100 gevallen een verkeerde oplossing in gedachten. Zolang je niet met custom classloaders, RMI of reverse engineering bezig bent, heb je reflection niet nodig.

[ Voor 41% gewijzigd door DaCoTa op 04-05-2004 15:31 ]

[Robtimus]

DaCoTa schreef op 04 mei 2004 @ 15:29:
Over reflection: als je een oplossing wilt verzinnen waar reflection bij komt kijken, heb je in 99 van de 100 gevallen een verkeerde oplossing in gedachten. Zolang je niet met custom classloaders, RMI of reverse engineering bezig bent, heb je reflection niet nodig.

Ik zal 1 voorbeeld noemen: swappable types. Als je zonder te moeten recompilen wil kunnen veranderen van gebruikt type.

Ik noem bv een Map. De ene keer kan een HashMap het handigst zijn, een andere keer een TreeMap.

Een ander voorbeeld wanneer reflection van pas komt (uit eigen ervaring): je wilt van een subklasse van iets @runtime bepalen of ze gelijk zijn, zonder dat je het precieze type weet. Je weet alleen dat ze van hetzelfde type zijn.
Wat doe je dan? Precies, reflection:

Java:

Field[] fields1 = object1.getClass().getDeclaredFields();
Field[] fields2 = object1.getClass().getDeclaredFields(); // gelijk type
for (int i = 0; i < fields1.length; i++)
{
    Object field = fields1[i].get(object1);
    if (!field.equals(fields2[i].get(object2)))
    {
        return false;
    }
return true;

(en ja, nu ik dit zie zie ik dat fields2 overbodig is )

[Soultaker]

IceManX kun je je punten misschien even toelichten? Ik begrijp van geen van beiden welke situatie je nu schetst en waarom die situatie het gebruik van reflection vereist.

[Robtimus]

Soultaker schreef op 04 mei 2004 @ 16:54:
IceManX kun je je punten misschien even toelichten? Ik begrijp van geen van beiden welke situatie je nu schetst en waarom die situatie het gebruik van reflection vereist.

Situatie 1:
Je gebruikt voor iets een java.util.Map (of een andere interface). Welke implementatie hiervan je gebruikt wil je alleen niet tijdens het compilen bepalen, maar pas tijdens runtime. Dan is reflection (in een van zijn eenvoudigste vormen) de enige optie.
Natuurlijk is dit een heel eenvoudig voorbeeld, maar als je gaat denken aan plugins wordt het natuurlijk al een stuk reeler. Zo heb ik voor school ooit eens een programma geschreven dat bestandsconversie toepaste. De convertor klassen waren volledig modulair en zonder de rest van het programma te hercompilen vervangbaar.

Situatie 2:
In mijn huidige project heb ik een data opslag van subklassen van klasse Tuple. Voor opzoeken moet ik tuples met elkaar vergelijken. Om het zo generiek mogelijk te houden gebruik ik dus eerder genoemd stuk code (ik zorg er zelf voor dat ik alleen match met gelijke klassen); ik hoef zo niet tijdens compile tijd te weten hoe de tuples er precies uitzien.
Voordat je nu zegt dat de matching in de tuples zelf moet zitten (ben ik met je eens hoor): dat vereist dat schrijvers van nieuwe tuples wel deze matching method moeten overschrijven / uitbreiden, en ik mag daar van mijn begeleiders niet vanuitgaan.

[Soultaker]

IceManX schreef op 04 mei 2004 @ 18:38:
Situatie 1:
Je gebruikt voor iets een java.util.Map (of een andere interface). Welke implementatie hiervan je gebruikt wil je alleen niet tijdens het compilen bepalen, maar pas tijdens runtime. Dan is reflection (in een van zijn eenvoudigste vormen) de enige optie.

Bedoel je niet gewoon zoiets:

Java:

Map mijnMap = (conditie) ? new HashMap() : new TreeMap();

Wat heeft dit met reflection te maken? Of bedoel je iets anders met "tijdens runtime bepalen welke implementatie je gebruikt"?

Situatie 2:
In mijn huidige project heb ik een data opslag van subklassen van klasse Tuple. Voor opzoeken moet ik tuples met elkaar vergelijken. Om het zo generiek mogelijk te houden gebruik ik dus eerder genoemd stuk code (ik zorg er zelf voor dat ik alleen match met gelijke klassen); ik hoef zo niet tijdens compile tijd te weten hoe de tuples er precies uitzien.
Voordat je nu zegt dat de matching in de tuples zelf moet zitten (ben ik met je eens hoor): dat vereist dat schrijvers van nieuwe tuples wel deze matching method moeten overschrijven / uitbreiden, en ik mag daar van mijn begeleiders niet vanuitgaan.

Hmz, je bedoelt dat je op die manier objecten kan vergelijken die geen equals methode hebben? Sorry hoor, maar dit vind ik een typische rommelige hack en rechtvaardigd naar mijn idee het gebruik van reflection absoluut niet. Van mensen die Java klassen schrijven mag je toch verwachten dat ze concepten als equality correct implementeren of anders de voor de hand liggende gevolgen accepteren.

[Robtimus]

Soultaker schreef op 04 mei 2004 @ 18:51:
Bedoel je niet gewoon zoiets:

Java:

Map mijnMap = (conditie) ? new HashMap() : new TreeMap();

Wat heeft dit met reflection te maken? Of bedoel je iets anders met "tijdens runtime bepalen welke implementatie je gebruikt"?

Dit was maar een eenvoudig voorbeeld natuurlijk, maar als je een aantal converters moet gebruiken die je tijdens het compilen nog niet weet, dan zit er niks anders op.
Bv

code:

converter0 = pdftohtml.PDFtoHTMLConverter
converter1 = tifftohtml.TIFFtoHTMLConverter
converter2 = htmltohtml.HTMLtoHTMLConverter
converter3 = pdftotext.PDFtoTEXTConverter
converter4 = tifftotext.TIFFtoTEXTConverter
converter5 = htmltotext.HTMLtoTEXTConverter

Doe dit maar eens zonder een Class.forInstance of een soortgelijke constructie.

Hmz, je bedoelt dat je op die manier objecten kan vergelijken die geen equals methode hebben? Sorry hoor, maar dit vind ik een typische rommelige hack en rechtvaardigd naar mijn idee het gebruik van reflection absoluut niet. Van mensen die Java klassen schrijven mag je toch verwachten dat ze concepten als equality correct implementeren of anders de voor de hand liggende gevolgen accepteren.

Ten eerste: het is geen volledige equality: een null waarde matcht alles. Dus als ik 2 String velden heb, en in mijn template maak ik die beide null, dan matcht alles van dezelfde klasse.

Ik ben het wel met je eens dat daarvoor een

Java:

public boolean match(<zelfde klasse>)

moet bestaan, maar dat mocht dus niet, ik had het al voorgesteld (zelfs in een eerdere periode geimplementeerd).

[zneek]

DaCoTa schreef op 04 mei 2004 @ 15:29:
Het lijkt erop dat je een mapping wil van String vakje naar String naam. Als je vooraf alle vakje - naam paren in een HashMap gooit, kun je ze er zo weer uit pielen met hashMap.get(vakje).toString();

Over reflection: als je een oplossing wilt verzinnen waar reflection bij komt kijken, heb je in 99 van de 100 gevallen een verkeerde oplossing in gedachten. Zolang je niet met custom classloaders, RMI of reverse engineering bezig bent, heb je reflection niet nodig.

Ben ik niet met je eens. Wij hebben een eigen aanpassing op BeanUtils gemaakt en die gebruikt reflection om van een bepaalde target bean methodes aan te roepen die overeenkomen met parameters in de request. Als er bijvoorbeeld een veld "naam" in de request zit probeert de custom beanutil de methode "setNaam" aan te roepen, maar niet voordat hij het type van het argument van "setNaam" bepaald heeft en de waarde behorende bij "naam" uit de request gecast/geconverteerd heeft naar een variabele van dat type.

Zonder reflection absoluut onmogelijk om te doen, wel erg nuttig en handig. Ik hoef namelijk maar 1 regel te programmeren om gegeven een bepaalde request mijn bean gevuld te krijgen: CustomBeanUtils.fillBean(target, request);

[ Voor 12% gewijzigd door zneek op 15-05-2004 09:31 ]

[ACM]

zneek schreef op 15 mei 2004 @ 09:28:
Ben ik niet met je eens.

Jouw voorbeeld is typisch dat 100e geval, waar je alleen maar een uitzondering op de regel die die regel bevestigd mee geeft

Probeer nog maar meer goede voorbeelden te bedenken, veel verder dan het Factory-pattern en zaken als BeanIntrospectors kom je niet, gok ik

IceManX schreef op 04 mei 2004 @ 19:03:
Dit was maar een eenvoudig voorbeeld natuurlijk, maar als je een aantal converters moet gebruiken die je tijdens het compilen nog niet weet, dan zit er niks anders op.
Bv

code:

converter0 = pdftohtml.PDFtoHTMLConverter
converter1 = tifftohtml.TIFFtoHTMLConverter
converter2 = htmltohtml.HTMLtoHTMLConverter
converter3 = pdftotext.PDFtoTEXTConverter
converter4 = tifftotext.TIFFtoTEXTConverter
converter5 = htmltotext.HTMLtoTEXTConverter

Doe dit maar eens zonder een Class.forInstance of een soortgelijke constructie.

Voor zulke dingen gebruikt men meestal een Factory, die eventueel "stiekem" reflection gebruikt, maar in je hoofdcode zou je het zo min mogelijk moeten toepassen.

Ten eerste: het is geen volledige equality: een null waarde matcht alles. Dus als ik 2 String velden heb, en in mijn template maak ik die beide null, dan matcht alles van dezelfde klasse.

Dat is een gevaarlijke uitspraak. Want een null-object matched ook niets, 't is maar net welke omgeving je mee werkt. In SQL geldt dat er uit bijna elke vergelijking met NULL, NULL volgt en volgens mij komt er in Java uit de volgende code false:

Java:

boolean checkObjects()
{
  Object A = null;
  Object B = null;
  return A == B;
}

Ik ben het wel met je eens dat daarvoor een

Java:

public boolean match(<zelfde klasse>)

moet bestaan, maar dat mocht dus niet, ik had het al voorgesteld (zelfs in een eerdere periode geimplementeerd).

Java definieert standaard een equals-methode (en een bijbehorende hashCode), kon je die niet gebruiken/herdefinieren ?

[.oisyn]

ACM schreef op 15 mei 2004 @ 11:00:
en volgens mij komt er in Java uit de volgende code false:

Java:

boolean checkObjects()
{
  Object A = null;
  Object B = null;
  return A == B;
}

Als daar false uit komt, hoe kun je dan controleren of iets null is?
A is hier gelijk aan B, namelijk null, dus dat zal in true resulteren

[Soultaker]

.oisyn schreef op 17 mei 2004 @ 13:09:
Als daar false uit komt, hoe kun je dan controleren of iets null is?
A is hier gelijk aan B, namelijk null, dus dat zal in true resulteren

Nou, dat zou natuurlijk kunnen met !(a==a) (impliceert a is null), maar je hebt gelijk dat dat in Java zo niet werkt.

[ACM]

.oisyn schreef op 17 mei 2004 @ 13:09:
Als daar false uit komt, hoe kun je dan controleren of iets null is?
A is hier gelijk aan B, namelijk null, dus dat zal in true resulteren

Mja, ik redeneerde met de SQL-gedachte in mijn hoofd. In theorie kunnen echter zowel A als B null zijn (dus A == null -> true) zonder dat ze gelijk aan elkaar zijn, want null impliceert "niets", niet "iets".
Dus A = null, B = null, maar dat zegt nog niet dat A == B!

A en B zijn beide twee, verschillende, lege pointers naar data (owja, het woord pointer mag je in java niet gebruiken natuurlijk )

[Robtimus]

.oisyn schreef op 17 mei 2004 @ 13:09:
[...]


Als daar false uit komt, hoe kun je dan controleren of iets null is?
A is hier gelijk aan B, namelijk null, dus dat zal in true resulteren

* Robtimus bevestigt dit na een test

[Alarmnummer]

ACM schreef op 17 mei 2004 @ 13:39:
[...]

Mja, ik redeneerde met de SQL-gedachte in mijn hoofd. In theorie kunnen echter zowel A als B null zijn (dus A == null -> true) zonder dat ze gelijk aan elkaar zijn, want null impliceert "niets", niet "iets".

Dat ligt er maar net aan hoe je er tegen aan kijkt. Als je het ziets als een bijzondere waarde, dan kun je gewoon ze met elkaar vergelijken. Met void het je precies zo`n probleem als je void ineens beschouwd als een waarde (waar je niets mee kan).

[drm]

ACM:
Mja, ik redeneerde met de SQL-gedachte in mijn hoofd.

In dat opzicht zou een null.equals ( a ) logischer zijn om te controleren of een reference null is, idd. Maar dat 't is wel een beetje puristisch geneuzel, imo