[JAVA] Runnable meerdere methods

[RomeoJ]

Ik ben momenteel bezig met een klein projectje voor mezelf. Nu heb ik wel al wat Java ervaring opgedaan, maar er is iets waar ik niet uitkom, misschien ook omdat ik de essentie er van dan niet snap.

Mijn probleem is dat ik meerdere classes heb gemaakt met de implementatie Runnable, waardoor ik die class dus kan Threaden als ik het uit wil voeren. So far so good..
Nu wil ik dus in deze class meerdere methods aanmaken, maar deze zijn dan niet Threadable, of beter gezegd ik krijg ze met geen mogelijkheid Threadable, het enige wat threaded wordt is de method run, lijkt het.

Ik krijg het uiteindelijk wel met een omweg aan de praat, door een nieuwe setter te maken die de naam van een method in een String stopt, en vervolgens via een lullig if-statement uitleest welke method de run moet uitvoeren.
Dit vind ik persoonlijk best smerig, en is niet goed onderhoudbaar, en tevens niet fail-safe, aangezien het een simpele String betreft.

Java:

public class RunClass implements Runnable
{
    private String method;


    public RunClass()
    {
    }


    public void setMethod(String method)
    {
        this.method = method;
    }


    public void run()
    {
        if(method.equals("TestMethod"))
        {
            this.TestMethod();
        }
        else if(method.equals("OtherMethod"))
        {
            this.OtherMethod();
        }
    }


    private void TestMethod()
    {
        System.out.println("Test 1");
    }


    private void OtherMethod()
    {
        System.out.println("Test 2");
    }
}

De versimpelde versie van mijn huidige class. Let wel dat dit slechts ter indicatie is, en niet de class in kwestie. Heb dus verschillende dingen geprobeerd, ook extends Thread, maar dit bleek de enige effectieve oplossing.

Graag wil ik dit dus beter doen, maar heb na verscheidene zoekopdrachten in F1 en Google geen bruikbare oplossing langs zien komen. De boeken die ik over Java bezit komen hier ook niet op terug en bieden dus ook geen oplossing.

Is hier een andere (lees: betere) oplossing voor?

[pedorus]

Waarom maak je niet gewoon meerdere classes die Runnable implementeren

[RomeoJ]

Dan zou ik van elke method een andere class moeten maken, dat zou een beetje uit de hand lopen.

Dit voorbeeld was slechts ter illustratie met twee methods, maar in de praktijk heb ik per class (5) ongeveer 10 á 20 methods, dat zou dus 50 tot 100 classes opleveren.
Als laatste weg is dat misschien een optie, maar ik ben gewoon benieuwd hoe ik mijn probleem op een efficiente en nette manier kan tackelen.

Het gaat mij niet alleen om een omweg te verzinnen, want dat was ook als eerste wat in mij opkwam om aparte classes aan te maken, maar ik ben gewoon leergierig en wil weten hoe dit door de professional opgelost wordt.

Maar; toch bedankt voor je inbreng!! Als laatste weg is dat zeker te overwegen, maar dan zou ik wel methods moeten omgooien.

[Salandur]

Dan is de door jouw gemaakte oplossing een goede manier om het te doen.

Ik vraag me echter af wat je precies probeert te bereiken?

[pedorus]

R3dn3ck schreef op donderdag 11 december 2008 @ 14:17:
Dan zou ik van elke method een andere class moeten maken, dat zou een beetje uit de hand lopen.

Dit voorbeeld was slechts ter illustratie met twee methods, maar in de praktijk heb ik per class (5) ongeveer 10 á 20 methods, dat zou dus 50 tot 100 classes opleveren.

En het probleem is? Dat doe je bij events in java toch vaak ook al (Anonymous inner classes)?
Je kan ze gewoon nesten voor de overzichtelijkheid. Vergelijk bijvoorbeeld:

Java:

RunClass method1 = new RunClass()
method1.setMethod("method1");
...

met iets als:

Java:

Runnable method1 = Methods.createMethod1();

[Zyppora]

Het enige wat hier volgens mij mis kan gaan, is dat de variabele method uitgevoerd wordt op het moment nadat de thread regel 19 uitgevoerd heeft, en voor regel 21. En zelfs dan kan je niet spreken van een thread-unsafe situatie. Je kunt dit oplossen door met semaforen te werken, of (dacht ik) de variabele method als synchronized te declareren.

Laat iemand mij alsjeblieft corrigeren als ik het mis heb, daar leer ook ik wat van

[ Voor 0% gewijzigd door Zyppora op 11-12-2008 17:08 . Reden: dat ding heet semafoor |:( ]

[RomeoJ]

Wat ik wil bereiken is heel simpel; betere onderhoudbaarheid, dacht namelijk dat er wel een betere oplossing voor zou zijn.

Ik wil namelijk gewoon de method aanroepen die ik wil gebruiken, zonder daarbij een if-statement te gebruiken om uit te lezen wat ik wil, want als er methodes bij komen dan moet ik die if-statement aanpassen, en zo is het totaalplaatje een beetje minder onderhoudbaar dan dat je direct de method kan aanroepen (zoals een "normale" class betaamt).

//Edit:
@pedorus: hmm, ja innerclasses zouden inderdaad ook mogelijk zijn, dat is denk ik wel een heel strak idee. Ik gebruik inderdaad Anonymous Inner Classes voor de Events.
Ik zou dan natuurlijk een "normale" class aan kunnen maken, en dan bij de EventHandler een runnable innerclass die de betreffende methode uit de "normale" class aanroept.
Puik plan, zover was ik nog niet, maar dat is denk ik de beste oplossing!!

[ Voor 35% gewijzigd door RomeoJ op 11-12-2008 15:13 ]

[Jaap-Jan]

metaforen

Ik wist niet dat die dingen zo heetten

[Janoz]

Je hoeft je class niet runnable te maken om methoden in een apparte thread uit te voeren.

Java:

        final RunClass runClass = new RunClass();
        new Thread(new Runnable(){
            public void run() {
                runClass.otherMethod();
            }
        }).start();

[sig69]

Je hebt dus een klein projectje waarin 50-100 methods in een thread wil kunnen uitvoeren. Je zou je ook af kunnen vragen of dit allemaal wel nodig is?

[Jrz]

getClass().getMethod(methodName).invoke(this);

[DaCoTa]

Jrz schreef op donderdag 11 december 2008 @ 15:26:
getClass().getMethod(methodName).invoke(this);

In 99% van de gevallen is reflection een bad idea. Grof gezegd, alleen als je compilers of frameworks maakt, zou je het nodig kunnen hebben.

[RomeoJ]

@Janoz; ik heb het nu inderdaad precies zo opgelost, met bijdrage van pedorus kwam ik tot het idee om dat zo op te lossen, werkte perfect zie ik.
Toch voel ik mezelf redelijk dom, want ik gebruik soortgelijke aanpak ook bij EventHandlers. Weer niet goed nagedacht.

@sig69; wij zullen wel een andere kijk op "een klein projectje" hebben.

@Jrz; zo zou het inderdaad ook nog kunnen, om die if-statement te killen.