On Jul 22, 2010, at 12:34 PM, James Carman wrote: > 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? >
James, Of all people I shouldn't have to tell you that one usecase is proxying. ;P -Matt >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
