Java design pattern: event system, multiple actions for a given actor

I have a system that manages events that happen to multiple actors using a simple queue-based system. Event is a simple class that has time and an abstract method fire(). Actor is a simple interface that implements two methods - think() and act(). Each actor has 2 basic events, that are implemented like that:

public class ActorThinkEvent extends Event {
    private Actor actor;

    public ActorThinkEvent(Actor actor, long time) {
        super(time);
        this.actor = actor;
    }

    public void fire() {
        Main.game.queue.add(actor.think());
    }
}

public abstract class ActorActEvent extends Event {
    protected Actor actor;

    protected ActorActEvent(Actor actor, long time) {
        super(time);
        this.actor = actor;
    }

    public void fire() {
        long spent = act();
        Main.game.queue.add(new ActorThinkEvent(actor, time + spent));
    }

    public abstract long act();
}

This way, "thinking" invocation is fixed, it is supposed to generate an ActorActEvent that would be added to the global queue, while "acting" invocation is done using a custom ActorActEvent-based class that implements the action, just returning the time spent, and new "think" event would be added to the queue automatically.

The problem I see here is that implementation of ActorActEvent-based classes comes down to simple delegation from ActorActEvent.act() to some method of Actor class with pre-stored arguments, i.e. all my ActEvent classes look very similar:

public class ActorMoveEvent extends ActorActEvent {
    private Coords delta;

    public ActorMoveEvent(Actor actor, long time, Coords delta) {
        super(actor, time);
        this.delta = delta;
    }

    public long act() {
        return actor.moveBy(delta);
    }
}

public class ActorReloadEvent extends ActorActEvent {
    public ActorReloadEvent(Actor actor, long time) {
        super(actor, time);
    }

    public long act() {
        return actor.reload();
    }
}

public class ActorPickupEvent extends ActorActEvent {
    private ItemStash wantedItems;

    public ActorPickupEvent(Actor actor, long time, ItemStash wantedItems) {
        super(actor, time);
        this.wantedItems = wantedItems;
    }

    public long act() {
        return actor.pickupItems(wantedItems);
    }
}

I might up end with several dozens of such classes. If I understand correctly, it's classic implementation of Command pattern. However, I don't feel good about all these delegation class开发者_JAVA技巧es and especially about writing them all manually.

I thought of using Java's reflection and stuff like Method.invoke(), while passing Method instance and pre-stored arguments to it in generic ActorActEvent class, however, it would be fairly slow. I thought of writing up a generator for all these classes, but it looks like a fairly clumsy solution to me.

If it would be some modern scripting/functional language, I'd end up using block/closure-like structure, preparing it first and invoking it when the time comes. Alas, I don't know how to make it efficiently in Java.

Are there any bright ideas on what can I do to improve the situation?

My advice is to go down the reflection path. Worrying that "it would be fairly slow" is premature in this case. The performance of reflection has been pretty decent for the past decade now, and you will be able to cache your Method objects to save the time spent reparsing names (which is probably the biggest performance hit). This approach is flexible and quick to implement.

If you really like your closures though, you can experiment with anonymous inner classes for your events. There are a few restrictions - you will still have to declare your methods so it is a little more verbose, and you'll need to declare your variables as final in order to access them from within the inner class. This approach will give you all the performance and safety of static types but you'll still have to have a class for each event.

Historically, events have exhibited a 'worst of both worlds' behaviour and passed around Objects, relying on the target to know how to cast and deal with them.