ITPub博客

首页 > 应用开发 > IT综合 > 从一个ConnectionPool的实现看design pattern的运用 (续六) (转)

从一个ConnectionPool的实现看design pattern的运用 (续六) (转)

原创 IT综合 作者:worldblog 时间:2007-12-12 12:56:29 0 删除 编辑
从一个ConnectionPool的实现看design pattern的运用 (续六) (转)[@more@] 

这种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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    6241
  • 访问量
    2465368