commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject [poll] [pool] picking descriptive class names
Date Sat, 25 Mar 2006 05:08:33 GMT
In the recently added composite pool code there are a number of
classes I think are misnamed. My head is so deep in the trees I'm not
sure I can see the forest. I'd like to get some opinions on which
names best express the intent of the pool feature before the names are
set in stone with a public release.

The main behavior of the composite pools are configured via four
type-safe enum types. I'll describe what each type controls and then
suggest name variants. Let me know which one you think is the most
self-evident and user friendly. Feel free to suggest new names.

1. "Specifies the how objects are borrowed and returned to the pool."
a) BorrowType  b) BorrowStrategy  c) BorrowPolicy  d) BorrowBehavior

2. "Specifies the behavior of the pool when the pool is out of idle objects."
a) ExhaustionPolicy  b) ExhaustionBehavior  c) ExhaustionType d)
ExhaustionStrategy

3. "Specifies the behavior of when there is a limit on the number of
concurrently borrowed objects."
a) LimitStrategy  b) LimitPolicy  c) LimitBehavior  d) LimitType

4. "Specifies how active objects are tracked while they are borrowed
from the pool."
a) TrackingBehavior  b) TrackingType  c) TrackingStrategy  d) TrackingPolicy

The enums above don't actually specify any implementation, they
describe desired features of a pool. The actual implementation isn't
broken down into four parts like that so try not to confuse how you
would implement that feature with how you would request that feature.


Some examples of each type might be:
Borrow: FIFO, SoftReference LIFO, Natural Order Ascending (implements
Comparable).
Exhaustion: Make a new object as needed or throw NoSuchElementException.
Limit: Wait for an object to be returned or throw NoSuchElementException.
Tracking: Keep a simple count of currently borrowed objects, use a
WeakReference to keep track of borrowed objects, don't bother tracking
borrowed objects.


I'm currently leaning towards the following names: BorrowStrategy,
ExhaustionPolicy, LimitPolicy, and TrackingStrategy. My rational is
that a Strategy is how you go and do something while a Policy is the
rules you use to make decisions. I'm not leaning towards the same
suffix (or prefix) because I've implemented these so they can be
converted into Java 1.5 enums for Pool 3 where they'll be grouped
separately in the JavaDocs.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message