I don't like that idea. 4 methods is a very small interface. You could provide a PoolListenerAdaptor class that implements the interface and stubs out all the methods for lazy people to extend ;-).

David



From: "Quinton McCombs" <[EMAIL PROTECTED]>
Reply-To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Subject: RE: [POOL] Pool listeners
Date: Fri, 28 Feb 2003 13:55:39 -0600


Actually four methods. There is also a remove event.

I generally don't care for switch statements either.

Another way to get the same effect would be to have four additional
interfaces that define the methods.  Example:

Public interface PoolListener
{
}

Public interface PoolListenerOnBorrow
{
    void onBorrow(Object obj) throws Exception;
}

Etc...

When you write an implementation of a PoolListener, you would implement
the PoolListener interface and each additional interface that
corresponds to the type of event that your implementation handles.

How does this idea sound?

> -----Original Message-----
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 1:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [POOL] Pool listeners
>
>
> Switch statements aren't very good OOP.  Looks like it's only
> 3 methods to
> implement anyways.
>
> My 2 cents.
>
> David
>
>
>
> >From: Tim Funk <[EMAIL PROTECTED]>
> >Reply-To: "Jakarta Commons Developers List"
> ><[EMAIL PROTECTED]>
> >To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> >Subject: Re: [POOL] Pool listeners
> >Date: Fri, 28 Feb 2003 14:28:31 -0500
> >
> >Would it be better to use some type of action code instead?
> For (a bad)
> >example:
> >   public final static int BORROW=0;
> >   public final static int RETURN=1;
> >   public final static int CREATE=2;
> >...
> >
> >Then the event could be fired by:
> >listenEvent(int action, Object o) and the implementor can
> use a switch
> >to
> >implement the correct action and not worry about
> implementing every method.
> >
> >This way, it is easier to maintain backwards compatibility
> in case of
> >new
> >listen events being introduced.
> >
> >-Tim
> >
> >
> >Quinton McCombs wrote:
> >>I am working on a patch to allow listeners to be added to
> pools that
> >>will receive notifications on various events.  Does anyone
> object to
> >>having this functionality included?
> >>
> >>Here is the design -
> >>
> >>I was thinking about adding support for a PoolListener
> interface for
> >>the pool component.  Object which implement this interface could be
> >>added to any ObjectPool or KeyedObjectPool.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to