signal and slot for java
Hi all,
I have implemented Qt's signal and slot here: http://sourceforge.net/projects/javasignalslot/
In case you are wondering what's "Qt's signal and slot", please read http://doc.trolltech.com/3.1/signalsandslots.html
My version uses String as signal, and the slot can be any public method. Currently ArrayList is used to setup the connection, for simplicity reason. In next release I will try to use HashTable and hopefully this can increase the signal propagation speed.
Please take a look and please give feedback to me. Thanks.
[568 byte] By [
tyctyctyca] at [2007-9-28 16:46:10]
> BTW, could you please elaborate more for why does it
> seem very closely related to the existing
> java.awt.Event mechanism?
OK, I'll try :-) And, re another poster's point, events are an implementation of the Observer pattern, so you might want to follow up on that.
To quote from your reference:
A signal is emitted when a particular event occurs. [...] A slot is a function that is called in reponse to a particular signal. [...] Signals are emitted by objects when they change their state in a way that may be interesting to the outside world.
Taking this to the Java world, a JButton generates events for button presses, releases, &c. If you're interested in these events, you register with the button as an ActionListener. When the event is fired, Swing takes care of notifying all the registered listeners that the event has fired, and provides them with the event.
Thank you.
ActionListener is an interface, but the slot only needs to be a public method of a class, therefore the only "contract" is the set of parameters for that method. The "observer" needs not implement an interface like ActionListener, but only prepares a public method and uses it as its "slot", so that the 齟vent notifier?can just call this method and pass the parameters it want.
At the time for setting up a "connection" (so that, in Swing sense, the "observer" will be able to get the notification), the only agreement between the signal and the slot is that set of parameters only; while for an object implementing ActionListener, the agreement is the entire ActionListener interface.
It wouldn't be useful to say "a set of method parameters" is better than "implementing an interface"; it is just that, "a set of method parameters" has lower requirement on the "contract", hence it will be more flexible.
No doubt in strict OO sense, any object, if it has certain kind of features, it should model that features into an interface, and implements it. However, interface would be a stronger "contract", which is more "heavy load" than just merely "a set of method parameters".
You might say that an interface will be sufficient, why I still want to make a method (which is more specific) independent of any interface (that it might/should have belonged to)? It is just another 齩bserver?mechanism, and probably just a dare try.
This idea, as you can see from the references, is the basic message passing mechanism among different modules. If my code, in your opinion, is worthy of trying, please give it a try. I will be glad to know if you like the idea.
