为什么我们给接口的实现名称加上前缀而不加后缀？

Question

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

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

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

我知道我正在搜索ConfigFileHandler，所以我键入ConfigFileHandler，然后我看到Apache并认为：“是的，我记得我要搜索的类是AppacheConfigFileHandler ”，因此我继续输入直到ConfigFileHandlerApache并查看AppacheConfigFileHandler的所有扩展/实现，最后找到我的FastApacheConfigFileHandler或ConfigFileHandlerApacheFast。

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

修改： 另一个要点：对我来说，当我读一个类名（从左到右）时，它越具体，我就越仔细地读了该类名，而并非以最详细的开头。

一个例子：当我从FastApacheConfigFileHandler读第一个单词Fast时，我不知道我在处理什么，然后我在阅读FastApache，仍然没有什么主意，然后我在读{{ 1}}，比我确切地知道即时通讯正在处理什么。与第一次阅读FastApacheConfigFileHandler时相比，我越了解类名，我就越了解我正在处理的内容并获得更多详细信息。

Answer 1

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

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

将其应用于java.util软件包：

• 您应该使用ListArray还是ListLinked？
• TokenizerString是什么？
• MapTree是树还是地图？ TaskTimer是计时器还是任务？
• LoaderService是一项服务吗？ ErrorConfigurationService呢？
• 等等。