确定对象的职责：实际例子

初写程序的时候，我们总是尽可能的使用JAVA的API，从这个角度来看，我们是类的用户。作为用户来讲，我们希望类的使用简单。

当我们在解决实际问题的时候，我们需要对客观世界进行建模，设计结构良好的类，并且使得类的职责尽可能的清楚和单一，类和类之间的关系能够正确建模客观世界。从这个角度来看，我们是类的作者。作为类的作者，我们设计好了类，供其他人所调用。

因此，在类的设计者之间和类的使用者之间存在者一个约定，这个约定就确定了程序的风格。
对于类的作者来说，如果他为了保证类方法的健壮性，那么他会要求类的使用者必须遵循类方法的入口条件：也就是说，传入的参数必须是什么样的，必须满足什么样的规则，否则就报错。因此，我们经常会看到程序中产生 IllegalParameterException异常，这个异常就是因为用户的输入参数不能满足方法的入口准则而抛出的。因此，类的设计者在方法开头会有一系列的参数检查，可能方法中实际有效的行数没有几行，更多的都是参数校验逻辑。这对类的开发者来说比较有利，但是，对于类的使用者就比较麻烦，因为他必须要保证传入的参数，否则，就不能得到想要的结果。
另外一种是将参数的校验交给使用者，使用者自行保证参数的正确性，调用类的方法就能够得到结果。这样，在使用方就会有比较多的参数校验逻辑，因为我们必须要保证传入 的参数是正确的。在平时的编程中，我们经常会写一些语句:
if(a!=null){
call(a,b);
}
就是因为这个原因。

在现实中，两种方式我们都会遇到。在开发过程中，只要在开发规范中定义好程序的编写方法以及入口检查机制，结果返回机制就没有问题。

上面是闲话了。
下面进入设计话题：Rebuild类到底需不需要检查文件在某个固定的目录下是否存在。

Rebuild这个类的作用是根据HSQLDB Script文件，重新构建HSQLDB的文件数据库或者内存数据库。对外提供的接口主要有：

* buildFileDBFromScriptFile(File scriptFile)
* buildMemDbFromScriptFile(File scriptFile)

这两个方法完成数据库的重新构建工作。在数据库的重新构建过程中可能发生的错误，比如：

* 数据库连接异常
* 重新数据库过程中出现的异常
* 数据库其他异常

都是要对其进行捕捉的。但是，是否也要检查待构建的文件是否已经存在。
但是，我想这已经不属于RebuildUtil类的问题了。在构建过程中发生的异常都要进行捕捉，这是良好的编程所需要的。但是，对于这个类可能使用的千变万化的场合，这个RebuildUtil怎么能预知呢？

比如说：如果有一个客户，希望即便有既定的目录下待构建的文件a已经存在，只需要改变文件名称为b就好了。然后就构建这个b数据库。那么我这个RebuildUtil应该怎么做呢？是不是需要在buildFileDBFromScriptFile(File scriptFile)中实现这个逻辑？
那如果其他客户再有不同的逻辑，比如删除已经存在的文件。
或者还有客户希望那就生成另外一个目录C，在目录C下生成文件就OK.

可以看到，这些是客户的使用逻辑，而非RebuildUtil中的重建数据库的逻辑。因此，这部分内容不属于RebuildUtil类的职责，因此，从这个方面讲，RebuildUtil不将检查文件是否存在，如果存在就删除之这样的逻辑放在RebuildUtil类中是完全合理的。

程序员在调用RebuildUtil的时候，应该自行保证File在当前的目录下没有被lock住，这就OK.