On Thu, Jul 22, 2010 at 12:44 PM, Michael Wooten <mwooten....@gmail.com> wrote: > I personally believe that there is a benefit for the EventSupport > interface, even if it can only register one type of listener. I also > believe that AbstractEventSupport could be very useful.
What is the usecase for the EventSupport interface? Unit testing? > provides an abstract base class for classes that are intended to work > much like PropertyChangeSupport works, with utility methods for > posting events and all of the listener management handled for you. The > idea is that you wouldn't have to create the event objects yourself, > you would just call utility methods that would create the event and > fire it. I am very impressed with James's implementation of > EventListenerSupport, and believe it is a much better solution than > the ReflectiveEventSupport class that I contributed. > I don't see any benefit in having an abstract superclass. Just have EventListenerSupport (perhaps rename it EventListeners?) and if you want to extend to provide custom "fire" methods, then just extend it and add them. No abstract class needed and if you want to use the class directly (by using the proxy to fire your methods "manually") you can. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
