这种ResourcesCollector的方法也有一点美中不足的地方，那就是，我们把我们在ResourceManImpl中使用java.util.Collection的实现细节暴露给了ResourcesCollection。如果一个ResourceMan的实现者不想用Collection，那就不太容易了。
你可以说，反正Collection是个interface, 我们可以让那个ResourceMan的实现者写一个adapter, 不就行了？
是啊。理论上是可以。但是，该死的Sun在Collection里面定义了太多的方法。而一些方法竟然是optional的。也就是说，如果一个ResourcesCollector的实现者使用了某个optional方法，编译器不会报错。而如果一个ResourceMan的实现者使用的容器并不支持这些optional的方法，编译器也不会报错。但是，当你把两者组装起来的时候，通！OperationNotSupportedException!
哎，要定义一个既要满足所有可能的ResourcesCollecor的要求 （如顺序存取，随机存取等等），又要让所有可能的ResourceMan都能实现的容器的接口是太困难了!
我想，这种要求应该是无解的。因为，ResourceMan和ResourcesCollector之间并不是足够松的耦合。概念上，ResourceMan必须选择一种能够符合ResourcesCollector的要求的容器。这就是它们之间需求上自然定义的耦合。所以，不存在一个可解除它们之间的耦合的完美解也就不值得惊讶了。
好在，ResourcesCollector只是ResourceMan功能的一个小子模块。它们之间如何组织并不影响我们整个pooling 框架系统。
下面，让我总结一下我们的pooling的框架系统的结构：
1. 可重用的pooling逻辑：
ResourceMan: 实现纯pooling算法逻辑，对具体的资源种类保持最大的透明度。
ResourceFactory: 用来封装资源生成逻辑，需要组合进ResourceMan.
ResourcesCollector: 用来封装整组资源回收，需要组合进ResourceMan。
ResourceCollector: 用来封装个体资源回收，需要组合进ResourcesCollector.
2.
PooledConnection: 封装Connection对象，使之与pool协调工作。
3.
ResourceMan2ConnectionPool: 类似于ConnectionMan2ConnectionPool, 负责使用PooledConnection来把一个不能对用户容错，对用户不透明的ResourceMan<Connection>转化成对用户安全透明的ConnectionPool.
要实现一个ConnectionPool,
1。 我们先要找一个合适的pooling逻辑，也就是一个ResourceMan的实现类，
2。 然后， 根据资源的特性，决定使用哪一个ResourcesCollector. 比如，为ConnectionPool使用LinearResourcesCollector<Connection>; 为thread 使用NopResourcesCollector.
3。因为Connection资源需要对单个资源进行释放，把ConnectionCollector交给LinearResourceCollector<Connection>
4。构造ResourceMan的对象实例。
5。 使用ResourceMan2ConnectionPool类把ResourceMan转换为ConnectionPool. ResourceMan2ConnectionPool会使用PooledConnection进行封装。
在以上的步骤中，还有一些共性可以提取。虽然用户自己来选购ResourceMan 和ResourceConnection<Connection>, 但对ConnectionPool来说，ResourcesCollector, ResourceCollector的实现都是固定的, ResourceMan2ConnectionPool也是固定使用的。
如果我们抽象这个过程， 可不可以是我们的用户接口更加简单呢？理想中，接口应该是这样：
public interface ResourceManFactory<R>{
public ResourceMan<R> getResourceMan(ResourceFactory<R> factory, ResourcesCollector<R> collector);
}
public class ConnectionPoolFactory{
public static ConnectionPool
getConnectionPool(ResourceManFactory<Connection> mf， ResourceFactory<Connection rf){
return mf.getResourceMan(rf,
LinearResourcesCollector<Connection>.instance(
ConnectionCollector.instance()
)
}
}
这样，构造ConnectionPool的人，只需要选择合适的ResourceManFactory 和ResourceFactory<Connection>, 其它什么都不用管了。不能再简单了。
实现pooling 算法的人，只需要研究他的算法，其它什么都不用管了。不能再简单了。
实现ResourceFactory<Connection>的人，只需要关注怎么连接数据库，其它什么都不用管了。不能再简单了。
一些桥接Connection和Resource的类都已经写好了。不用管它们。
实现封装Connection或其它Resource的人，只需要关注那个资源的接口和语义，做出适当对pool逻辑的调整，其它什么都不用管了。不能再简单了。
