Paths.get против Path.of


20

Насколько я могу сказать, Paths.getи, Path.ofкажется, делаю то же самое, превращая одну или несколько строк в Pathобъект; документация https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html#get-java.lang.String-java.lang.String...- и https: //docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/Path.html#of(java.lang.String,java.lang.String ... ) используйте ту же формулировку. Они на самом деле идентичны?

Path.ofбыл введен позже. Гипотеза: это было введено ради последовательного Foo.ofстиля. В таком случае, это будет считаться предпочтительным по согласованности / эстетическим соображениям?


5
Я думаю, что вы правы. Быстрый поиск по спискам обсуждения Java поднял это: mail.openjdk.java.net/pipermail/nio-dev/2018-March/004810.html Все еще читаете, чтобы написать ответ.
Йоханнес Кун,

2
Я предпочитаю, Path.ofпотому что это не требует дополнительного импорта
Жека Козлов

Ответы:


22

Верно, Path.of позже был представлен.

Гипотеза: это было введено ради последовательного Foo.of стиля.

Из архива списка рассылки этот метод когда-то вызывалсяPath.get :

Основные изменения в пути и пути в java.nio.file.

Этот патч копирует методы Paths.get () в статические методы в Path.get () и модифицирует первый для вызова последних соответствующих методов. Спецификация Path немного очищена, чтобы не ссылаться ни на Paths, ни на себя, например, «(см. Path)». Аннотации @implSpec добавляются в Path, чтобы указать, что методы просто вызывают свои аналоги в Path.
...

Позже это изменилось, когда Брайан Гетц предложил, чтобы это соответствовалоFoo.of :

Отдельно Брайан Гетц предложил вне списка, что было бы более согласованным, если бы эти фабричные методы были названы «of», поэтому я предполагаю, что webrev будет обновлен, чтобы увидеть, как это выглядит.

Теперь к вашему последнему вопросу: «В таком случае, это будет считаться предпочтительным по согласованности / эстетическим соображениям?»
В первоначальном письме Брайан Буркхальтер сказал, что он обновил все ссылки на новый метод вPath :

Все исходные файлы в java.base изменены, чтобы изменить Paths.get () на Path.get () и удалить импорт для Paths. ...

Поэтому я бы пришел к выводу, что Path.ofдействительно предпочтительнее Paths.get.
Действительно, если вы посмотрите на Javadoc Pathsдля Java 13 вы найдете следующее примечание:

Примечание API :
рекомендуется получать Pathчерез Path.ofметоды, а не через getметоды, определенные в этом классе, так как этот класс может быть устаревшим в будущем выпуске.


5
Помните, что NIO.2 был представлен в Java 7, когда статические методы в интерфейсах были невозможны. Так что нужен был класс-компаньон Paths. Использование фабричного метода интерфейса уменьшает количество типов, с которыми приходится иметь дело. Стиль именования - это просто еще один момент, который был пересмотрен, поскольку появилась такая возможность.
Хольгер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.