java - 为什么我们在接口(interface)的实现名称前面加上前缀而不是后缀？

Question

我明白了，我们从左到右阅读
ApacheConfigFileHandler implements ConfigFileHandler
听起来比
好 ConfigFileHandlerApache implements ConfigFileHandler
当说话时。

但是当我搜索类时，我通常知道我正在寻找的接口(interface)，但通常不知道确切的实现名称。
我知道我正在寻找 ConfigFileHandler ，但我可能不知道我正在寻找的实现名称是“Apache”。
因此，在代码补全方面，通过后缀方法，我可以搜索 ConfigFileHandler然后它会建议我 ConfigFileHandler 的所有实现，包括 AppacheConfigFileHandler 。

当继承层次结构更大时，后缀方法的优点变得更加明显:
假设我有
FastApacheConfigFileHandler extends ApacheConfigFileHandler
这将是
ConfigFileHandlerApacheFast extends ConfigFileHandlerApache
使用后缀方法。

我知道我正在寻找ConfigFileHandler所以我输入ConfigFileHandler ，然后我看到 Apache 并想“是的，我记得我正在搜索的类是 AppacheConfigFileHandler ”，所以我继续输入直到 ConfigFileHandlerApache并查看 AppacheConfigFileHandler 的所有扩展/实现终于找到我的FastApacheConfigFileHandler又名 ConfigFileHandlerApacheFast .

实现名称后缀方法有什么问题吗(除了听起来不太好听)？
如果是的话，有什么问题吗？如果不是，为什么这种方法没有成为标准？

编辑:另一点:这对我来说更有意义，当我阅读一个类名(从左到右)时，我读得越深入，它就会变得越具体，并且不会从最详细的开始。

举个例子:当我读到 FastApacheConfigFileHandler 中的第一个单词“Fast”时，我不知道我在处理什么，然后我正在阅读 FastApache，仍然没有太多想法，然后我正在阅读 FastApacheConfigFileHandler ，比我确切地知道我在处理什么。与我读 ConfigFileHandler 时相比首先，我知道我正在处理什么，并随着我进一步阅读类名而获得更多详细信息。

Answer 1

我认为最重要的原因是它完全违反了标准Java命名约定和英语语言语义。这样做违反了 principle of least astonishment .

采用这种方法自然得出结论，类名变得完全棘手。

将其应用到java.util包:

• 您应该使用 ListArray或 ListLinked ？
• TokenizerString 会怎样？是？
• 是 MapTree一棵树还是一张 map ？是TaskTimer计时器还是任务？
• 是 LoaderService一项服务？ ErrorConfigurationService怎么样？ ？
• 等等