大多数面向对象语言的接口名称都以大写的I开头，为什么Java不这样做呢?不遵循这一惯例的理由是什么?
为了证明我的意思，如果我想有一个用户界面和一个用户实现，我在Java中有两个选择:
类=用户，接口= UserInterface 类= UserImpl，接口=用户
在大多数语言中:
类=用户，接口= IUser
现在，您可能会争辩说，您总是可以为用户实现选择一个最具描述性的名称，这样问题就解决了，但Java正在推动POJO方法，大多数IOC容器广泛使用dynamicproxy。这两件事加在一起意味着您将使用单个POJO实现拥有许多接口。
所以，我想我的问题可以归结为:“是否值得遵循更广泛的接口命名约定，尤其是考虑到Java框架的发展方向?”
当前回答
遵循良好的OO原则，您的代码应该(尽可能地实际/可能)依赖于抽象而不是具体类。例如，通常更好的方法是这样写的:
public void doSomething(Collection someStuff) {
...
}
比这个:
public void doSomething(Vector someStuff) {
...
}
如果您遵循这个想法，那么我认为，如果您为接口命名为“User”和“BankAccount”(例如)，而不是“IUser”、“UserInterface”或其他变体，那么您的代码将更具可读性。
唯一应该关心实际具体类的代码是具体类的构造位置。其他所有内容都应该使用接口编写。
如果您这样做了，那么像“UserImpl”这样“难看”的具体类名应该安全地隐藏在代码的其余部分中，这些代码可以愉快地继续使用“漂亮”的接口名。
其他回答
在c#中是这样的
public class AdminForumUser : UserBase, IUser
Java会说
public class AdminForumUser extends User implements ForumUserInterface
正因为如此，我认为在java中，约定对于接口来说并没有那么重要，因为继承和接口实现之间有明显的区别。我会说选择任何你喜欢的命名约定，只要你是一致的，并使用一些东西向人们展示这些是接口。我已经好几年没有使用java了，但是所有的接口都在它们自己的目录下，这是惯例。从来没有什么问题。
根据我的经验，“I”约定适用于旨在向类提供契约的接口，特别是当接口本身不是类的抽象概念时。
例如，在您的例子中，如果您希望拥有的唯一用户是user，那么我只希望看到IUser。如果您计划使用不同类型的用户——NoviceUser、ExpertUser等等——我希望看到一个User接口(也许还有一个实现了一些常见功能的AbstractUser类，比如get/setName())。
我还希望定义功能(Comparable、Iterable等)的接口这样命名，而不是IComparable或IIterable。
我不喜欢在接口上使用前缀:
前缀损害了可读性。 在客户端中使用接口是编程的标准最佳方式，因此接口名称应该尽可能简短而美观。实现类应该更加丑陋，以阻止它们的使用。 当从抽象类更改为接口时，前缀为I的编码惯例意味着重命名类的所有出现项——这不好!
在Wicket框架中也使用了“I”前缀，我很快就习惯了它。一般来说，我欢迎任何缩短笨重Java类名的约定。但是，在目录和Javadoc中，所有东西都按字母顺序排列在“I”下面，这很麻烦。
Wicket的编码实践类似于Swing，因为许多控件/小部件实例被构造为带有内联方法声明的匿名内部类。令人恼火的是，它与Swing有180度的不同，Swing为实现类使用前缀(“J”)。
“Impl”后缀是一个蹩脚的缩写，不能很好地国际化。如果我们至少用“小恶魔”的话，它会更可爱(也更短)。“Impl”用于IOC，特别是Spring，所以我们现在有点被它困住了。不过，在一个代码库的三个不同部分遵循三种不同的约定有点分裂。
这是真正意义上更广泛的命名惯例吗?我更倾向于c++，而不是Java及其后代。有多少语言社区使用I约定?
如果这里有独立于语言的商店标准命名约定，请使用它。如果不是，请遵循语言命名约定。
