Best practice is declaring an event as part of a Java interface

Question

I am trying to separate some UI code using interfaces and events, and I would like to know if there is a way / best practice in Java for declaring an event as part of a Java interface - something like what C # provides:

// C# event declaration in interface public interface IAction { event EventHandler OnAction; } 

My goal is simply to mark the interface so that it is known that it (the developers) fires events of a certain type. I hope that I can include more than documentation just to enforce this behavior. I understand that Java does not provide the keyword “event” or a direct way to do this, so I hope for some tips on a workaround or best practice for achieving this.

One way I can do this is to create a universal marker interface that provides the ability to fire events:

 public interface FiresEvent<T extends Event> { public void fireEvent(); } 

... and then inherit this interface in my user interface.

 public interface MyInterface extends FiresEvent<ActionEvent> { } 

The problem with this approach is that a FiresEvent can only be inherited once, even if the generic type is changed, so the solution does not seem generic enough for the case when an object can be the source of several events.

I would be interested to know how people deal with this, and if there is a better way than just documenting the need to trigger events.

EDIT: Maybe the following question will clarify my question:

I understand the Java handler list approach and do it yourself by letting callers register object handlers. In my case, I rely on the event bus, so we can view the "shooting" events as placing them there, to redirect something else to the handlers.

I would like to define the responsibility of the interface as:

• An interface designer fires an event of type T on the world / event / anything bus
• An interface designer should not delegate to the most registered users.

Answer 1

Java handles events a little differently than what you are used to, but the concept is the same. You create what is called an event listener, and it is called when an event occurs. This may be a better design since it allows you to register multiple listeners.

I suggest viewing this tutorial

Answer 2

Method availability

  registerXListener(XListener listener) 

in the interface indicates that the class will send XEvents to those who need it. That is, the "marker" is another method. The closest analogue to the C # idiom (I think) would be to bring this method up to the interface, for example

 public interface XEventFirer { public void registerXListener(XListener listener) } 

Answer 3

This seems like a natural place to use annotations. I met EventBus , which uses annotations to publish and subscribe to events. This approach is naturally self-documenting and, depending on how it is implemented, can make your code more readable and possibly allow you to annotate.