Почему операции над Path реализованы в виде статических методов?

Question

Почему операции над Path реализованы в виде статических методов?

1

IMHO, path.delete() выглядит немного лучше, чем Files.delete(path). Но разработчики пакета java.nio.file предпочли реализовать операции над Path в форме статических методов Paths. Зачем?

Jofsey 16 март 2014, в 21:24

Источник

Теги:

java

file

coding-style

java-7

2 ответа

Ещё вопросы

Joop Eggen · Answer 1 · 2014-03-16T17-53-00.000Z

Это утилитарные реализации, шаблон дизайна, как в коллекции/коллекциях, файле/файлах, пути/пути. Пути могут обрабатывать разные (виртуальные) "файловые" системы, такие как zip файловая система. Следовательно, путь связан с файловой системой, и delete делегирует, тем не менее, удаление файловой системы. Например:

Для zip файловой системы представление может иметь путь c:\data\x\y файлу c:\data\x\y zip path relative x/y. Вы можете перемещать/переименовывать/копировать между путями. Наличие файловых операций в пути будет чистым делегированием вызовов.

Они решили позволить Path быть чистой структурой данных даже больше, чем File, немного похожим на URL.

Таким образом, существует некоторое обоснование кода. Но согласился, имея несколько классов, возможно, смешанный (Path + File + Paths + Files), не делает для чистого дизайна стиля API.

Sotirios Delimanolis · Answer 2 · 2014-03-16T16-44-00.000Z

Поскольку, как утверждает Javadoc, Path

Объект, который может использоваться для поиска файла в файловой системе. Обычно он представляет собой системный зависимый путь к файлу.

Это не файл, он просто описывает путь к файлу. Поэтому ничего не удалять или удалять не имеет смысла на пути. Это имеет смысл только в файле.

Тогда мой вопрос: зачем иметь такую слабую абстракцию пути вместо фактически-файловой абстракции?
@Lescott Я бы сказал, разделение проблем . Но вам нужно будет спросить дизайнеров языка для полного ответа.