Paths.get与Path.of
据我所知,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
样式。在那种情况下,从一致性/美学的角度来看,这会被认为是可取的吗?
回答:
确实,Path.of
后来才介绍。
猜想:引入它是为了保持一致的
Foo.of
样式。
从邮件列表档案中,该方法曾经被称为Path.get
:
的主要更改是在java.nio.file中的路径和路径中。
此修补程序将Paths.get()方法复制到Path.get()中的静态方法,并修改前者以调用后者各自的方法。略微清理了路径规范,使其既不引用路径也不引用路径本身,例如“(请参阅路径)”。@implSpec批注将添加到Paths,以指示方法仅在Path中调用其对应方法。
…
后来,当Brian
Goetz建议与以下内容保持一致Foo.of
时,此更改被更改:
另外,Brian Goetz建议从列表中删除,如果将这些工厂方法命名为“ of”,则将更加一致,因此我假设将对webrev进行更新以查看其外观。
现在,您要问的最后一个问题是:“在那种情况下,从一致性/美学角度考虑,它是否可取?” Brian Burkhalter
在第一封邮件中说,他在以下位置更新了对该新方法的所有引用Path
:
修改了java.base中的所有源文件,以将Paths.get()更改为Path.get()并删除Paths的导入。…
因此,我得出的结论Path.of
确实比更好Paths.get
。
确实,如果您查看适用Paths
于Java
13的Javadoc,则会发现以下说明:
:
建议使用
Path
viaPath.of
方法而不是通过get
此类中定义的方法来获取,因为在将来的发行版中可能不推荐使用此类。
以上是 Paths.get与Path.of 的全部内容, 来源链接: utcz.com/qa/436138.html