这种ResourceSCOllector的方法也有一点美中不足的地方,那就是,我们把我们在ResourceManImpl中使用Java.util.Collection的实现细节暴露给了ResourcesCollection。如果一个ResourceMan的实现者不想用Collection,那就不太容易了。XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />
你可以说,反正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转化成对用户安全透明的ConnectionPool.
要实现一个ConnectionPool,
1。 我们先要找一个合适的pooling逻辑,也就是一个ResourceMan的实现类,
2。 然后, 根据资源的特性,决定使用哪一个ResourcesCollector. 比如,为ConnectionPool使用LinearResourcesCollector; 为thread 使用NopResourcesCollector.
3。因为Connection资源需要对单个资源进行释放,把ConnectionCollector交给LinearResourceCollector
4。构造ResourceMan的对象实例。
5。 使用ResourceMan2ConnectionPool类把ResourceMan转换为ConnectionPool. ResourceMan2ConnectionPool会使用PooledConnection进行封装。
在以上的步骤中,还有一些共性可以提取。虽然用户自己来选购ResourceMan 和ResourceConnection, 但对ConnectionPool来说,ResourcesCollector, ResourceCollector的实现都是固定的, ResourceMan2ConnectionPool也是固定使用的。
如果我们抽象这个过程, 可不可以是我们的用户接口更加简单呢?理想中,接口应该是这样:
public interface ResourceManFactory{
public ResourceMan getResourceMan(ResourceFactory factory, ResourcesCollector collector);
}
public class ConnectionPoolFactory{
public static ConnectionPool
getConnectionPool(ResourceManFactory mf, ResourceFactory
return mf.getResourceMan(rf,
LinearResourcesCollector.instance(
ConnectionCollector.instance()
)
}
}
这样,构造ConnectionPool的人,只需要选择合适的ResourceManFactory 和ResourceFactory, 其它什么都不用管了。不能再简单了。
实现pooling 算法的人,只需要研究他的算法,其它什么都不用管了。不能再简单了。
实现ResourceFactory的人,只需要关注怎么连接数据库,其它什么都不用管了。不能再简单了。
一些桥接Connection和Resource的类都已经写好了。不用管它们。
实现封装Connection或其它Resource的人,只需要关注那个资源的接口和语义,做出适当对pool逻辑的调整,其它什么都不用管了。不能再简单了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752043/viewspace-991980/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10752043/viewspace-991980/