Имеет ли смысл использовать `java.nio.file.spi` для реализации доступа к удаленной файловой системе?

Похоже, вы думаете о создании класса RemoteFileSystemProvider специально для вашей удаленной файловой системы. Этот класс будет отражать FileSystemProvider, предоставляя аналогичные функции для доступа к удаленной файловой системе, которую вы используете. Если это то, что может многократно использоваться в вашем проекте или команде, то при создании кода стоит отразить объект FileSystemProvider. Это позволяет любому, кто знаком с пакетом java.nio.file, легко понять, как использовать ваш.

Однако имейте в виду, что FileSystemProvider сам по себе не соответствует никаким интерфейсам и не расширяет какие-либо классы внутри пакета. Это точка входа, и ваш класс также будет точкой входа. Однако, если вы имитируете структуру метода, вы будете генерировать объекты Channel для чтения и записи, которые будут соответствовать спецификациям java.nio, которые можно использовать повторно. Это позволит любому коду, который знает, как работать с каналами, иметь возможность работать с каналами, созданными вашим поставщиком удаленной файловой системы.

Однако моим первым шагом в создании чего-то подобного было бы создание пакета специально для этой удаленной файловой системы. Он будет обрабатывать все коммуникации и реализовывать основные функции, такие как getUploadChannel, getDownloadChannel, renameRemoteFile, copyRemoteFile, deleteRemoteFile, и любые другие необходимые функции. Это даст вам хороший интерфейс, основанный на здравом смысле, определенный для этой конкретной файловой системы и ее функций. Этот пакет можно использовать в любом контексте, чтобы просто реализовать соединение с этой файловой системой. Если вы убедитесь, что этот объект использует каналы для загрузки и скачивания файлов, он будет готов к интеграции с любым API, использующим java.nio.

Только после того, как это будет завершено, протестировано и заработает, я мог бы подумать, какой интерфейс я хотел бы имитировать или реализовать для доставки остальной части команды. Это гарантирует, что любые изменения протокола удаленной файловой системы или Java API будут иметь минимальное влияние на всю систему.