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

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

转载于:http://blog.itpub.net/10752043/viewspace-991980/