On Mon, 2 Apr 2001 [EMAIL PROTECTED] wrote:
> [snip]
> First, I really don't like mixing the tests with the actual code. I don't
> know how difficult it would be to have a sparate directory ( even if it
> uses the same package name to access package-protected methods).
>
I like separate directories for the tests as well -- my preferred approach
is visible in the beanutils build.xml file.
> [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.
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.
Without interfaces, we might as well go back to coding in C :-).
> Finally, I don't like the fact the lack of notifications - that's related
> with the current design as an abstract interface/implementation instead of
> using the "java bean" pattern ( component / event-listeners ).
>
It would be straightfoward to add event/listener abstractions as
well, although (for efficiency) you might want to allow an
implementation to no-op them. The set of events should be extensible via
specialization for the same reason that you want to create sub-interfaces
for extended behavior of your pool implementations.
> 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.
> Costin
>
Craig
