[
https://issues.apache.org/jira/browse/POOL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923794#action_12923794
]
Gary Gregory commented on POOL-173:
-----------------------------------
Thank you for the diagrams. I do not like the constructor zoo either.
IMO, these constructors should allow to build legal instances. Since there are
default values for all config options, I would argue that we need one
constructor that lets you set them all and one that lets you set none which
means you get the defaults. I would also have a constructor that accepts a
config object.
For example, instead of:
- GenericObjectPool(PoolableObjectFactory<T>)
- GenericObjectPool(PoolableObjectFactory<T>, Config)
- GenericObjectPool(PoolableObjectFactory<T>, int)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
boolean, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, boolean, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, boolean, boolean, long, int, long, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, int, boolean, boolean, long, int, long, boolean)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, int, boolean, boolean, long, int, long, boolean, long)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, int, boolean, boolean, long, int, long, boolean, long, boolean)
You only need:
- GenericObjectPool(PoolableObjectFactory<T>)
- GenericObjectPool(PoolableObjectFactory<T>, Config)
- GenericObjectPool(PoolableObjectFactory<T>, int, WhenExhaustedAction, long,
int, int, boolean, boolean, long, int, long, boolean, long, boolean)
The other constructors are just noise IMO.
> Better config without duplication.
> ----------------------------------
>
> Key: POOL-173
> URL: https://issues.apache.org/jira/browse/POOL-173
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Gary Gregory
> Priority: Minor
> Fix For: 2.0
>
> Attachments: commons-pool2-configExisting.dia,
> commons-pool2-configExisting.png, pool2config.diff
>
>
> There is code duplication in configuration code.
> I'd like to track an experiment here.
> > -----Original Message-----
> > From: Gary Gregory [mailto:[email protected]]
> > Sent: Wednesday, October 20, 2010 10:44
> > To: Commons Developers List
> > Subject: RE: [pool] Reusing Config
> >
> > In the same department, I see the following ivars:
> >
> > lifo : boolean
> > maxActive : int
> > maxIdle : int
> > maxTotal : int
> > maxWait : long
> > minEvictableIdleTimeMillis : long
> > minIdle : int
> > numTestsPerEvictionRun : int
> > testOnBorrow : boolean
> > testOnReturn : boolean
> > testWhileIdle : boolean
> > timeBetweenEvictionRunsMillis : long
> > whenExhaustedAction : WhenExhaustedAction
> >
> > defined in four classes:
> >
> > GenericKeyedObjectPool
> > GenericKeyedObjectPoolFactory
> > GenericObjectPool
> > GenericObjectPoolFactory
> >
> > Which feels to me like a missed opportunity to avoid duplication.
> >
> > Is making one ivar private or final or volatile be applied to all four
> > classes?
> >
> > We could:
> >
> > Use a config object instead of the 13 ivars.
> > Or a common superclass then we can consider if it should hold the ivar list
> > or
> > a Config object.
> >
> > Would it be too weird to have a common super class for BaseObjectPool and
> > BasePoolableObjectFactory for example?
> >
> > Gary Gregory
> > Senior Software Engineer
> > Rocket Software
> > 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
> > Tel: +1.404.760.1560
> > Email: [email protected]
> > Web: seagull.rocketsoftware.com
> >
> >
> >
> > > -----Original Message-----
> > > From: Gary Gregory [mailto:[email protected]]
> > > Sent: Wednesday, October 20, 2010 10:29
> > > To: Commons Developers List
> > > Subject: [pool] Reusing Config
> > >
> > > Hi All:
> > >
> > > I think this came up recently. Any thoughts or plans on extracting the
> > Config
> > > class out of GenericKeyedObjectPool and GenericObjectPool so it can be
> > reused.
> > > The constants for default values could then also be moved to Config.
> > > Gary Gregory
> > > Senior Software Engineer
> > > Rocket Software
> > > 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
> > > Tel: +1.404.760.1560
> > > Email: [email protected]<mailto:[email protected]>
> > > Web: seagull.rocketsoftware.com<http://www.seagull.rocketsoftware.com/>
> > >
> >
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
