[
https://issues.apache.org/jira/browse/POOL-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172084#comment-13172084
]
Phil Steitz commented on POOL-203:
----------------------------------
I tend to agree with Mark on this. It may be a matter of taste; but I see it
as desirable actually that "the main code" be aware of the internals of this
particular data structure. It makes the code easier for me to understand and
trace. There are a lot of things that you have to hold in your head when
working with this code, no matter how you cut it and having more of the
structure immediately evident makes it a little easier to work with. Better
in-line and javadoc documentation explaining all of the invariants and
contracts is definitely needed; but I am not sure more data abstraction will
really help much at this point. Also, the first two above are likely trivial
because they are not accessed that frequently, but the last one might have a
slight negative performance impact, as it is very frequently activated and,
like the other two, forces an additional stack operation to activate the
wrapper function.
> GenericKeyedObjectPool.ObjectDeque could be better encapsulated
> ---------------------------------------------------------------
>
> Key: POOL-203
> URL: https://issues.apache.org/jira/browse/POOL-203
> Project: Commons Pool
> Issue Type: Improvement
> Reporter: Sebb
> Priority: Minor
>
> GenericKeyedObjectPool.ObjectDeque is currently basically just a collection
> of Objects with getters.
> This necessarily exposes the implementation, and makes adding invariant
> checks a lot harder - e.g. ensuring createCount >=0.
> The suggestion is to replace the getters with functional methods, for example:
> objectDeque.getCreateCount().incrementAndGet() => objectDeque.createdEntry();
> objectDeque.getAllObjects().put(t, p); => objectDeque.addNew(t, p);
> objectDeque.getIdleObjects().addFirst(p)/addLast(p) =>
> objectDeque.idle(p,getLifo())
> The new methods could include assertions for invariants, and adding debug
> would be a doddle.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
