为什么Java.NIO使用静态方法？

Question

为什么Java.NIO使用静态方法？

3

我想知道为什么java.nio基于静态方法，我的意思是在java.io中，你创建一个文件然后使用它的方法，像这样：

File file = new File("myFile");
FileReader fileReader = new FileReader(file);
BufferedReader bufferedReader = new BufferedReader(fileReader);
String readLine = bufferedReader.readLine();

每个对象都有自己的方法。

java.nio 的工作方式不同，您需要使用静态方法，并强制始终将要处理的文件作为参数传递。

Path file = Paths.get("myFile");
BufferedReader bufferedReader = Files.newBufferedReader(file);
String readLine = bufferedReader.readLine();

Path source = Paths.get("source");
Path target = Paths.get("target");
Files.copy(source, target);

nio提供了实用方法（例如newBufferedReader）直接在类中使用，因此编写的代码更少。但是也可以使用实例方法完成此操作，这样就不必将路径作为参数传递。

为什么要改变这种范式？有什么隐藏的优势呢？

- David Marciel

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Thilo · Accepted Answer

在你展示的例子中，模式是通过工厂方法隐藏构造函数调用。这是一种非常成熟的方法，允许实现在实际返回哪种类型的实现方面具有灵活性。这使得复杂逻辑和未来演变都可以在其中封装起来。即使它不适用于您引用的示例，也有可能根本不创建新实例，而是返回缓存的副本(例如Integer.valueOf与new Integer相反)。

如果直接调用构造函数，则无法实现此灵活性。

nio提供了有用的方法(如newBufferedReader)直接在类中提供，因此编写的代码更少。但是它也可以在实例方法中完成，这样你就不必将路径作为参数传递。

像path.newBufferedReader()这样的形式可能会将这些类之间的耦合度过高。他们希望Path成为一个表示文件系统路径的类。它不需要知道人们可能想对文件进行的所有操作。专注和独立的类有助于实现模块化。

对于旧的API，他们采取了另一种方式，请参见String#replaceAll。在这里，理解正则表达式的整个逻辑已经集成在了String类中。