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

Question

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

将协议特定位封装在文件系统服务提供程序接口中是否是一种好方法？

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

Answer 1

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

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

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

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

Answer 2

我会沮丧并且使用类似FTP的协议。在高级API上实现低级API的麻烦在于，您可以掩盖所有真正的成本，并使事情变得简单，实际上非常困难或昂贵。例如，考虑seek（）。