On Mon, 2 Apr 2001, Craig R. McClanahan wrote:

> > [snip]
> > Another thing I don't like is the interfaces. I think it would be far
> > better to just create a component that does pooling - instead of creating
> > to define APIs ( as an interface sugests). It's very unlikely other pools
> > will implement the same interfaces - we can later define some interfaces
> > after we have 2-3 pool implementations and we know what they have in
> > common and what's the use pattern, if we really need to.  
> > 
> 
> I think object pooling is a place where multiple implementations of the
> same contract, but with different internal behaviors, is *definitely*
> useful.  Therefore, I prefer the proposed design based on interfaces and
> multiple implementations.

As long as the contract is the right one.

Most of the time is very difficult to get the right interfaces - and many
times it's better to not have an interface than to have a bad interface,
and wait to get feedback and alternative implementations before going
defining the interfaces.

I don't want to give examples :-)


> If you have one, or a family of, implementations that have common behavior
> over and above the standard, it is straightforward to define your own
> subinterface to define the common behavior of your family, and use this
> subinterface in your implementations.

The keyword here is "standard": if this proposal is for creating a thread
pool standard, I'm -1 on it ( for many reasons ). Just creating some
interfaces doesn't make it a "standard".


> > Of course, it's all a matter of taste - and what matter is the taste of
> > the user, who can pick the component that he needs. 
> > 
> 
> If you code based on implementation classes rather than interfaces, then
> you are also stuck with your choice.  That's why things like
> java.util.List and java.util.Map are interfaces not classes.

Again, it's a matter of taste. If this proposal expects other  pool
implementations to implement that same interfaces and define a standard
for pools that everyone else will accept and use - interfaces are fine.


Costin

Reply via email to