java为什么我们在接口的实现名称前加前缀而不是后缀？

Question

我知道，我们从左到右阅读 ApacheConfigFileHandler implements ConfigFileHandler
听起来比
好 ConfigFileHandlerApache implements ConfigFileHandler
说话的时候

但是当我搜索一个类时，我通常知道我要寻找的接口，但通常不知道确切的实现名称
我知道我正在寻找一个ConfigFileHandler，但我可能不知道我正在寻找的实现名称是“Apache”
因此，在代码完成方面，使用后缀方法，我可以搜索ConfigFileHandler，然后它会向我建议ConfigFileHandler的所有实现，包括AppacheConfigFileHandler

当继承层次结构更大时，后缀方法的优势变得更加明显：
假设我有
FastApacheConfigFileHandler extends ApacheConfigFileHandler
哪个是
ConfigFileHandlerApacheFast extends ConfigFileHandlerApache
使用后缀方法

我知道我正在搜索一个ConfigFileHandler，所以我键入ConfigFileHandler，然后我看到Apache并想“是的，我记得我正在搜索的类是AppacheConfigFileHandler”，所以我继续键入直到ConfigFileHandlerApache，查看AppacheConfigFileHandler的所有扩展/实现，最后找到我的FastApacheConfigFileHandlerakaConfigFileHandlerApacheFast

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

编辑： 另一点：这对我来说更有意义，当我阅读类名（从左到右）时，我读得越深入，它就越具体，而不是从最细节开始

举个例子：当我从FastApacheConfigFileHandler读第一个单词Fast时，我不知道我在处理什么，然后我在读fastache，仍然不是什么好主意，然后我在读FastApacheConfigFileHandler，我不知道我在处理什么。Vs当我首先阅读ConfigFileHandler时，我有点知道我在处理什么，并且得到了更多的细节，我读的类名越深

Answer 1

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

采用这种方法自然得出结论，类名变得完全难以处理

将其应用于java.util包：

• 你应该使用^{}还是^{}
• 什么是^{}
• a^{}是树还是地图？一个^{}是计时器还是任务
• a^{}是一种服务吗？那^{}呢
• 等等