java - 使用`java.nio.file.spi`实现对远程文件系统的访问有意义吗？

Question

基本上，我编写了一个应用程序，它通过一些类似 FTP 的协议将文件从本地文件系统复制/移动到远程文件系统。

将特定于协议的位封装在文件系统服务提供者接口内是否是一种好方法？

据我了解，这将使我的库与使用新 IO API 的其他应用程序一起工作，对吧？

Answer 1

您似乎正在考虑RemoteFileSystemProvider专门为您的远程文件系统创建一个类。此类将 mirror FileSystemProvider，提供类似的功能来访问您正在使用的远程文件系统。如果这是您的项目或团队可以重复使用的东西，那么FileSystemProvider在创建代码时镜像对象是值得的。这使任何熟悉该java.nio.file软件包的人都可以轻松了解如何使用您的软件包。

但是请记住，它FileSystemProvider本身不符合任何接口或扩展包中的任何类。它是一个入口点，您的班级也将是一个入口点。但是，如果您模仿方法结构，您将生成Channel要读取和写入的对象，这将符合java.nio可重用的规范。这将允许任何知道如何使用通道的代码都能够使用远程文件系统提供程序生成的通道。

然而，我构建这样的东西的第一步是专门为这个远程文件系统构建一个包。它将处理所有通信并实现基本功能，如getUploadChannel, getDownloadChannel, renameRemoteFile, copyRemoteFile,deleteRemoteFile以及任何其他必要的功能。这将为您提供为该特定文件系统及其功能定义的良好常识接口。这个包可以在任何上下文中使用来实现到这个文件系统的连接。如果您确保此对象使用通道来上传和下载文件，那么它将准备好与任何使用java.nio.

只有在完成、测试和工作之后，我才会考虑我想模仿或实现哪个接口以交付给团队的其他成员。这将确保对远程文件系统协议或 java API 的任何更改将对整个系统产生最小的影响。

Answer 2

我会变得肮脏并使用类似 FTP 的协议。在高级 API 之上实现低级 API 的问题在于，你掩盖了所有真正的成本，让事情看起来很容易，但实际上非常困难或昂贵。以 seek() 为例。