大多数面向对象语言的接口名称都以大写的I开头，为什么Java不这样做呢?不遵循这一惯例的理由是什么?
为了证明我的意思，如果我想有一个用户界面和一个用户实现，我在Java中有两个选择:
类=用户，接口= UserInterface 类= UserImpl，接口=用户
在大多数语言中:
类=用户，接口= IUser
现在，您可能会争辩说，您总是可以为用户实现选择一个最具描述性的名称，这样问题就解决了，但Java正在推动POJO方法，大多数IOC容器广泛使用dynamicproxy。这两件事加在一起意味着您将使用单个POJO实现拥有许多接口。
所以，我想我的问题可以归结为:“是否值得遵循更广泛的接口命名约定，尤其是考虑到Java框架的发展方向?”
当前回答
在Wicket框架中也使用了“I”前缀，我很快就习惯了它。一般来说，我欢迎任何缩短笨重Java类名的约定。但是，在目录和Javadoc中，所有东西都按字母顺序排列在“I”下面，这很麻烦。
Wicket的编码实践类似于Swing，因为许多控件/小部件实例被构造为带有内联方法声明的匿名内部类。令人恼火的是，它与Swing有180度的不同，Swing为实现类使用前缀(“J”)。
“Impl”后缀是一个蹩脚的缩写，不能很好地国际化。如果我们至少用“小恶魔”的话，它会更可爱(也更短)。“Impl”用于IOC，特别是Spring，所以我们现在有点被它困住了。不过，在一个代码库的三个不同部分遵循三种不同的约定有点分裂。
其他回答
遵循良好的OO原则，您的代码应该(尽可能地实际/可能)依赖于抽象而不是具体类。例如，通常更好的方法是这样写的:
public void doSomething(Collection someStuff) {
...
}
比这个:
public void doSomething(Vector someStuff) {
...
}
如果您遵循这个想法，那么我认为，如果您为接口命名为“User”和“BankAccount”(例如)，而不是“IUser”、“UserInterface”或其他变体，那么您的代码将更具可读性。
唯一应该关心实际具体类的代码是具体类的构造位置。其他所有内容都应该使用接口编写。
如果您这样做了，那么像“UserImpl”这样“难看”的具体类名应该安全地隐藏在代码的其余部分中，这些代码可以愉快地继续使用“漂亮”的接口名。
我不喜欢在接口上使用前缀:
前缀损害了可读性。 在客户端中使用接口是编程的标准最佳方式，因此接口名称应该尽可能简短而美观。实现类应该更加丑陋，以阻止它们的使用。 当从抽象类更改为接口时，前缀为I的编码惯例意味着重命名类的所有出现项——这不好!
这是真正意义上更广泛的命名惯例吗?我更倾向于c++，而不是Java及其后代。有多少语言社区使用I约定?
如果这里有独立于语言的商店标准命名约定，请使用它。如果不是，请遵循语言命名约定。
在c#中是这样的
public class AdminForumUser : UserBase, IUser
Java会说
public class AdminForumUser extends User implements ForumUserInterface
正因为如此，我认为在java中，约定对于接口来说并没有那么重要，因为继承和接口实现之间有明显的区别。我会说选择任何你喜欢的命名约定，只要你是一致的，并使用一些东西向人们展示这些是接口。我已经好几年没有使用java了，但是所有的接口都在它们自己的目录下，这是惯例。从来没有什么问题。
Java通常不使用IUser约定可能有几个原因。
Part of the Object-Oriented approach is that you should not have to know whether the client is using an interface or an implementation class. So, even List is an interface and String is an actual class, a method might be passed both of them - it doesn't make sense to visually distinguish the interfaces. In general, we will actually prefer the use of interfaces in client code (prefer List to ArrayList, for instance). So it doesn't make sense to make the interfaces stand out as exceptions. The Java naming convention prefers longer names with actual meanings to Hungarian-style prefixes. So that code will be as readable as possible: a List represents a list, and a User represents a user - not an IUser.
