“Do-er”类与静态实用方法

Question

假设您拥有FileReader类，read方法。

我知道类级属性可以证明拥有一个实例。但是，通过在相应的ReaderUtils static方法的范围内提取这些相同的属性，停止创建等效的read类是什么？

简而言之，对于静态实用方法而言，“Doer”类的确切原因是什么？

Answer 1

接口无法静态实现 - 接口的实现方法必须是实例方法。因此，这禁止injection或JNDI查找“实用程序类”作为执行某些服务的运行时实现 - 它必须是类的实例。这是“doer”类存在的主要原因之一。

如果在编译时已知实现，则实用程序类很好，并且作为静态方法，它们更可能自然是无状态的（只需确保任何静态字段是不可变的/无状态的），这是服务于请求的典型服务器所必需的同时进行。

Answer 2

OOP的本质是封装状态/数据以及相关的行为。静态实用程序方法类似于过程语言中的全局函数 - 您将行为（静态方法）与状态（参数与此方法）分离，从而破坏了封装。

这在实践中意味着什么？您不必调用reader.read()，而是调用ReaderUtils.read(file)，这意味着您现在与实现紧密耦合 - 您已经隐含假设您将始终使用ReaderUtils并且总是传入一个文件。

如果您改为使用通用Reader界面，则今天可以使用FileReader但明天将其换成DatabaseReader或HttpReader，而无需更改任何内容其他代码 - 所有reader.read()调用将继续有效。

Answer 3

这是一个偏好问题。一般来说，Java偏爱名词（因为人们觉得这更像是OO）因此FileReader。

正如杰弗里所指出的，有时名词的痴迷会导致不必要的冗长，在这种情况下，调用会被静态方法包裹起来。