What's the most efficient way to use event handlers?

[Bedrock_Miner]

Heyho guys!

 

I came across this question while I was creating my new mod.

I know three different ways to set up proper event handlers, like the examples here:

 

Event Handler 1:

 

Main.class:

public void initEventHandlers() {
  MinecraftForge.EVENT_BUS.register(new EventHandlerGameOverlay());
  FMLCommonHandler.instance().bus().register(new EventHandlerInput());
}

EventHandlerGameOverlay.class:

@SubscribeEvent
public void onGameOverlay(RenderGameOverlayEvent e) {
  [...]
}

EventHandlerInput.class:

@SubscribeEvent
public void onKeyPressed(KeyInputEvent e) {
  [...]
}

@SubscribeEvent
public void onMouse(MouseEvent e) {
  [...]
}

Basic idea of this event handler type: Every kind of event has its own event handler, so that they are logically divided into seperate classes. Every eventhandler is registered seperately.

Event Handler 2:

 

Main.class:

public void initEventHandlers() {
  MinecraftForge.EVENT_BUS.register(new EventHandler());
  FMLCommonHandler.instance().bus().register(new EventHandler());
}

EventHandler.class:

@SubscribeEvent
public void onGameOverlay(RenderGameOverlayEvent e) {
  [...]
}

@SubscribeEvent
public void onKeyPressed(KeyInputEvent e) {
  [...]
}

@SubscribeEvent
public void onMouse(MouseEvent e) {
  [...]
}

Basic idea of this event handler type: Every event is handled in a single class. This class is registered to both event buses.

Event Handler 3:

 

Main.class:

public void initEventHandlers() {
  MinecraftForge.EVENT_BUS.register(new EventHandlerController());
  FMLCommonHandler.instance().bus().register(new EventController());
}

EventHandlerController.class:

SubscribeEvent
public void onGameOverlay(RenderGameOverlayEvent e) {
  EventHandlerGameOverlay.onGameOverlay(e);
}

@SubscribeEvent
public void onKeyPressed(KeyInputEvent e) {
  EventHandlerInput.onKeyPressed(e);
}

@SubscribeEvent
public void onMouse(MouseEvent e) {
  EventHandlerInput.onMouse(e);
}

EventHandlerGameOverlay.class:

public void onGameOverlay(RenderGameOverlayEvent e) {
  [...]
}

EventHandlerInput.class:

public void onKeyPressed(KeyInputEvent e) {
  [...]
}

public void onMouse(MouseEvent e) {
  [...]
}

Basic idea of this event handler type: The event handlers are located in seperate classes to be logically divided but they are called by a single event handler which is the only handler of this mod which is registered to the buses.

 

 

 

I wonder, which of these different methods is the best one regarding orderliness of the code, time efficiency of the program and amount of code. Or is this indifferent altogether?

 

Please tell me what you think about this!

[Draco18s]

I use a variant of #2, myself

 

public void initEventHandlers() {
  EventHandler evHandle = new EventHandler();
  MinecraftForge.EVENT_BUS.register(evHandle);
  FMLCommonHandler.instance().bus().register(evHandle); //OBJECT REUSE, HEYO
}

[Ernio]

Personally I've separated:

Common:

*ForgeEvents

*FMLEvents

Client:

*ClientForgeEvents

 

and hadn't a chance to make ClientFMLEvents yet.

 

I register whole class once in proxy and in case of Client events I do that in client proxy ofc.

 

I doubt that there is any difference here other than readability.

[Anon10W1z]

I use a variant of #2, myself

 

public void initEventHandlers() {
  EventHandler evHandle = new EventHandler();
  MinecraftForge.EVENT_BUS.register(evHandle);
  FMLCommonHandler.instance().bus().register(evHandle); //OBJECT REUSE, HEYO
}

I take it one step further and make my event handler final. Then I store the singleton instance of the event handler in itself.

[Bedrock_Miner]

Doesn't this make your code a bit messy if every single event your mod is receiving is located in one class?

[herbix]

I usually register event handler like this:

...
public class MyItem extends Item {
...
    public MyItem() {
        ...
        MinecraftForge.EVENT_BUS.register(this);
        ...
    }

    @SubscribeEvent
    public void onXX(XX event) {
        ...
    }
}

 

But I have no idea about whether it's not a efficient way(both programming and executing).

Of course, this event has close relations with the item.

[Anon10W1z]

Doesn't this make your code a bit messy if every single event your mod is receiving is located in one class?

If you use comments and JavaDoc it will look much nicer.

[coolAlias]

I doubt that having more or fewer classes really makes a difference as far as efficiency.

 

If your mod is running slowly, profile your code and see where the bottleneck is, then optimize that, but don't prematurely sacrifice clean organization of your project for what you imagine may be more efficient code.

 

In my case, I keep logical groups of events together in the same class, e.g. all my combat-related events go in CombatEventHandler class, whereas my world gen events go in GenEventHandler, etc. Some of these are registered to multiple buses, but most just one. For GuiOverlays, I make one class per overlay, treating it like any other GUI even though it uses an event.

 

Keeping client events separate is also nice, as then you can have a class member for Minecraft.getMinecraft and other such things that would crash your game otherwise.

 

Everyone has their personal preferences, and you should just choose one that makes sense for you and your project.

[jabelar]

I like keeping the number of event handling classes small because then it is less of a pain to register them and you won't forget to register one.  To me having lots of separate classes is "messier" than having them all grouped in one handler.  I do create a separate handler class for each bus though, so I have the regular one, the FML one, ore gen one, terrain gen one.  So basically one handler registered to each bus.

 

I suppose it depends on how complicated your event handling methods are.  Most of mine are about 15 lines or less of code, so it is not too unwieldy to have them all in one class.

 

As mentioned above, I don't think there would necessarily be any efficiency effect in the different approaches, although I suspect that having more classes means that the event bus needs to iterate more (would need a compiler expert to comment on that).  But mostly it is a coding style preference.