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

Question

假设您有FileReader一个带有read方法的类。

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

简而言之，关于静态实用程序方法，究竟是什么证明了“Doer”类的合理性？

Answer 1

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

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

Answer 2

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

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

如果您改为使用通用Reader接口，则可以使用 a FileReadertoday 但将其换成 aDatabaseReader或HttpReader明天，而无需更改任何其他代码——所有reader.read()调用将继续以相同的方式工作。

Answer 3

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

正如 Jeffrey 所指出的，有时对名词的痴迷会导致不必要的冗长，此时调用会被包含在静态方法中。