[java] variabele method namen

[Verwijderd]

Ik heb in mijn progje een thread draaien die kijkt naar een Socket input. De input is altijd xml. Nu wil ik de thread bepaalde methodes laten aanroepen aan de hand van inkomende xml elementen.
ik wil de methodes en objecten die moeten worden aangeroepen kunnen doorgeven aan de thread met een bepaalde functie, bijv:

code:

InputSocketXMLReader.registerHandler("elementnaam", HandlerObject, "handlerMethod");

elke keer als er nu een <elementnaam>blah</elementnaam> binnen komt moet HandlerObject.handlerMethod(..Binnengekomen Data..) worden aangeroepen.

Ik ben op het idee gekomen door de methode van variabele functie namen in php. Is zoiets ook mogelijk in Java. Ik heb hier op het forum gezocht en op google maar kon niets vinden. Neem dus aan dat het niet kan. Weet iemand dan misschien een andere goede manier om methodes van objecten te kunnen doorgeven aan andere methodes zodat die deze kunnen uitvoeren?

[mbravenboer]

Reflectie: java.lang.reflect.*;

Je kunt aan een Class via de naam van een methode een Method instantie krijgen. Daarop kan je methode 'invoke' aanroepen met parameters .

[mbravenboer]

Zie ook de Java Tutorial:

http://java.sun.com/docs/books/tutorial/reflect/index.html

Ik zou hoet overigens niet al te veel misbruiken als vervanging voor een goed design.

Het zit trouwens ook in mijn DispatchingContentHandler van gisteren.

[Verwijderd]

ok ik wist nog niet wat reflectie was, zag het wel staan in je code. Ben nog niet zo gevorderd met Java. Een programma maken bestaat voor mij vooral JavaDocs doorpluizen naar objecten die methodes ontvangen. Ga ik nu ook doen voor Reflectie

[Verwijderd]

Ik zou hoet overigens niet al te veel misbruiken als vervanging voor een goed design.

Wat bedoel je hier mee. Is het langzaam / "slecht"? Dus alleen gebruiken als het niet anderes kan?

edit:

Sorry voor de twee berichten achter elkaar, gebeurt niet nog een keer

[mbravenboer]

SurfingFromAM2PM: Wat bedoel je hier mee. Is het langzaam / "slecht"?

Het is tegenwoordig behoorlijk snel althans: invocatie. Het verkrijgen van een Method object uit een Class duurt behoorlijk lang. De invocatie zelf is erg snel (vergelijkbaar met gewone methode invocatie). Als je dus heel vaak een bepaalde methode moet aanroepen kan je beter je Method object cachen. Dat doe ik dus ook in de DispatchingContentHandler .

Dus alleen gebruiken als het niet anderes kan?

Ja, je compiler kan er niets mee. Je verliest allerlei controles en overzichtelijkheid. Vaak kan je hetzelfde effect ook bereiken met behulp van interfaces (eventueel dan wel in combinatie met dynamic class-loading om onbkende klassen te instantieren).

[mbravenboer]

SurfingFromAM2PM: Sorry voor de twee berichten achter elkaar, gebeurt niet nog een keer

Zo streng zijn we hier nu ook weer niet hoor . Zeker niet als het ergens over gaat .

[Verwijderd]

Op zondag 27 januari 2002 15:12 schreef mbravenboer het volgende:

[..]

Zo streng zijn we hier nu ook weer niet hoor . Zeker niet als het ergens over gaat .

je bedoelt cker niet als het over JAVA gaat...

vb: hoe maak je hello word ik java

[MisterData]

code:

public class Blaat {
   public static void main(String[] args) {
    System.out.println("Hello World");
   }
}

[Verwijderd]

mbravenboer schreef op 27 January 2002 @ 14:57:
Zie ook de Java Tutorial:

[url="http://java.sun.com/docs/books/tutorial/reflect/index.html"]http://java.sun.com/docs/books/tutorial/reflect/index.html[/url]

Ik zou hoet overigens niet al te veel misbruiken als vervanging voor een goed design.

Het zit trouwens ook in mijn DispatchingContentHandler van gisteren.

Hoezo misbruiken ter vervanging van een goed design? Een goed design gebruikt design patterns. Dan kan het toch niet anders, of je gebruikt constructies? Vooral method Class.forName is toch onmisbaar?

Of is er een andere manier om design-patterns efficient toe te passen in Java?

[mbravenboer]

(Merkwaardige kick na een jaar?)

Keessie131: Hoezo misbruiken ter vervanging van een goed design? Een goed design gebruikt design patterns. Dan kan het toch niet anders, of je gebruikt constructies? Vooral method Class.forName is toch onmisbaar?

Het advies was om goed na te denken voordat je reflectie gaat toepassen. In sommige situaties kan reflectie erg handig zijn, maar als je het gebruik van reflectie kan voorkomen met een goed design (bijvoorbeeld met het gebruik van design patterns) moet je reflectie uiteraard voorkomen.

Class.forName is niet direct de vorm van reflectie die ik zeer zou willen afraden. Class.forName is met geschikt voor het gebruiken van at compile time onbekende klassen, die echter wel voldoen aan een bepaalde interface via welke je deze klassen gebruiken. Bij serieuze reflectie kom je toch met name op Method.invoke, waarbij je dus volledig op basis van methode namen at runtime bepaalde methoden gaat aanroepen.

Of is er een andere manier om design-patterns efficient toe te passen in Java?

Ik ken geen enkel design pattern die het gebruik van reflectie verplicht eerlijk gezegd.

[Glimi]

Verwijderd schreef op 13 januari 2003 @ 16:36:
Of is er een andere manier om design-patterns efficient toe te passen in Java?

Ik ken niet zo'n directe vorm van reflectie als Java heeft in C++ en daar schrijf ik toch patterns in. Rara hoe doe ik dat?

Keyword van patterns is vaak 'interfaces' en 'polymorphisme' Door een generiekheid te creëren in een interface en je niet te bekommeren om de implemententatie zijn vaak zeer generieke pattronen op te zetten. Ik weet niet hoe _juist_ een implementatie specefiek iets als een Class.forName() daar iets mee te maken kan hebben.

Tevens is een Class.forName nou niet echt 'denderende' reflectie. Het brengt iig niet echt verwarring/gevaar met zich mee. Echte reflectie kan veel 'engere' dingen. Bijv, private var's benaderen, methods van een class invoken en passen als parameter (vergelijkbaar met functionpointers in C++ ) Hiermee ben je voor een deel bezig met het 'openbreken' van een class en dat is JUIST een van de dingen die we niet graag zien.

[ Voor 10% gewijzigd door Glimi op 13-01-2003 21:56 ]

[mbravenboer]

Glimi: Echte reflectie kan veel 'engere' dingen. Bijv, private var's benaderen

Dat kan overigens niet als er een serieuze SecurityManager is: in normale applicaties is het mogelijk, maar in applets bijvoorbeeld al niet.

[Glimi]

mbravenboer schreef op 13 januari 2003 @ 22:52:
Dat kan overigens niet als er een serieuze SecurityManager is: in normale applicaties is het mogelijk, maar in applets bijvoorbeeld al niet.

Klopt, maar wat er 'eng' aan is, is dat het een encapsulatie brekende vorm in de hand werkt. Mensen gaan het dan gebruiken in situaties waar andere oplossingen mooier, flexibeler en bovenal meer OO geweest waren.
En dat was juist een van de cornerstones van Java, veilig programmeren door oa de 'bad habits of programming' niet toe te laten. Hier doel ik dan op dingen als globale variabelen en methodes bijvoorbeeld

Neemt niet weg dat het een mooie feature is, waar ik af en toe ook niet vies van ben (een mooie generieke equals bijvoorbeeld dmv reflection is mogelijk)

[mbravenboer]

Glimi: maar wat er 'eng' aan is, is dat het een encapsulatie brekende vorm in de hand werkt.

Dat zal ik ook zeker niet bestrijden .

Gelukkig is het ook wel weer zo lastig gemaakt dat het niet snel gebruikt zal worden . Velen zullen de mogelijkheid geeneens kennen.

[Verwijderd]

Ik ken geen enkel design pattern die het gebruik van reflectie verplicht eerlijk gezegd.

Deze post is alleen van toepassing als Class.ForName ook een 'vorm' van reflectie is.

Stel dat je het command pattern wilt implementeren.

ALs eenvoudig voorbeeld neem ik ff command interpreter in java (een soort 'dos-prompt').

Daarvoor kan je mooi het command design pattern gebruiken. De parent class zou er zo uit kunnen zien:

code:

public class Command {
 public void execute(String parameter);
 public String getResultText();
}

Mogelijke commando's zijn bijvoorbeeld: mkdir, rmdir, chdir

In de actieve thread heb je een variabele command, waar het commando in staat. Dan kan je toch goed op de volgende manier het design pattern toepassen:

code:

while (true)  {
// ... resultaat ophalen van commando-string
// ... commando wordt in command string geparsed
// ... parameters worden in parameters string geparsed

String result;
try {
  Class myClass = Class.forName("packagenaam."+command+"Command");
  Command myCommand = myClass.newInstance();
  myCommand.execute(parameters);
  result = myCommand.getResultText();

}
catch(Exception e) {
  result =  "Commando bestaat niet, of foute parameters opgegeven"; 
}

Of zouden jullie het aanmaken van commando dan als volgt regelen:

code:

command myCommand;
if (command.equals("mkdir"))
  myCommand = new mkdirCommand();
else if (command.equals("rmdir"))
  myCommand = new rmdirCommand();
// en zo alle andere commando's + afhandeling van de code

[Alarmnummer]

Dan moet je natuurlijk wel even ons niet zulke lelijke code geven. Je zou uitstekend die commands 1 keer kunnen aanmaken en die in een map kunnen plaatsen op basis van hun naam. Daar heb je verder geen reflection voor nodig (ook niet deze vorm)

[ Voor 11% gewijzigd door Alarmnummer op 14-01-2003 09:19 ]

[Verwijderd]

De code is niet echt netjes, maar het voorbeeld duidelijk genoeg toch?

[Alarmnummer]

Het ging me erom dat jouw stuk code bij de 'forname' waarschijnlijk gebruikt maakt van een map. Hierbij kan je dus vrij efficient de juiste class vinden. Wij krijgen een enorm lelijke if else reeks ipv ook een map oplossing.

*weet ook nog niet zo goed wat hij moet denken van reflection...

[Verwijderd]

Het coole effect van dynamisch klassen includen is dat je at runtime uit kunt breiden. Ook hoef je bestaande coden in sommige gevallen (zoals dit geval) niet aan te passen om nieuwe functionaliteit toe te voegen.

[bluewarlord]

Ik wil niet zeuren, maar volgens mij heeft die helemaal geen reflectie nodig. Een hash oplossing kan ook, waarbij de keys van de hash de xml tag is en de value een parsing object is die een bepaalde interface implementeerd.

[Verwijderd]

Een hash oplossing kan ook, waarbij de keys van de hash de xml tag is en de value een parsing object is die een bepaalde interface implementeerd.

Het coole effect van dynamisch klassen includen is dat je at runtime uit kunt breiden. Ook hoef je bestaande coden in sommige gevallen (zoals dit geval) niet aan te passen om nieuwe functionaliteit toe te voegen.

Dat heeft het dus voor voordelen boven een Hash

[ Voor 5% gewijzigd door Verwijderd op 14-01-2003 14:18 ]