大多数面向对象语言的接口名称都以大写的I开头，为什么Java不这样做呢?不遵循这一惯例的理由是什么?
为了证明我的意思，如果我想有一个用户界面和一个用户实现，我在Java中有两个选择:
类=用户，接口= UserInterface 类= UserImpl，接口=用户
在大多数语言中:
类=用户，接口= IUser
现在，您可能会争辩说，您总是可以为用户实现选择一个最具描述性的名称，这样问题就解决了，但Java正在推动POJO方法，大多数IOC容器广泛使用dynamicproxy。这两件事加在一起意味着您将使用单个POJO实现拥有许多接口。
所以，我想我的问题可以归结为:“是否值得遵循更广泛的接口命名约定，尤其是考虑到Java框架的发展方向?”
当前回答
这是真正意义上更广泛的命名惯例吗?我更倾向于c++，而不是Java及其后代。有多少语言社区使用I约定?
如果这里有独立于语言的商店标准命名约定，请使用它。如果不是，请遵循语言命名约定。
其他回答
还有另一种约定，被包括Spring在内的许多开源项目所使用。
interface User {
}
class DefaultUser implements User {
}
class AnotherClassOfUser implements User {
}
我个人不喜欢“I”前缀，原因很简单，它是一个可选的约定。所以，如果我采用这种IOPConnection意味着接口的IOPConnection?如果类没有“I”前缀，那么我是否知道它不是一个接口呢?这里的答案是否定的，因为约定并不总是遵循的，监管它们将创建更多的工作，而约定本身节省了。
我不喜欢在接口上使用前缀:
前缀损害了可读性。 在客户端中使用接口是编程的标准最佳方式，因此接口名称应该尽可能简短而美观。实现类应该更加丑陋，以阻止它们的使用。 当从抽象类更改为接口时，前缀为I的编码惯例意味着重命名类的所有出现项——这不好!
遵循良好的OO原则，您的代码应该(尽可能地实际/可能)依赖于抽象而不是具体类。例如，通常更好的方法是这样写的:
public void doSomething(Collection someStuff) {
...
}
比这个:
public void doSomething(Vector someStuff) {
...
}
如果您遵循这个想法，那么我认为，如果您为接口命名为“User”和“BankAccount”(例如)，而不是“IUser”、“UserInterface”或其他变体，那么您的代码将更具可读性。
唯一应该关心实际具体类的代码是具体类的构造位置。其他所有内容都应该使用接口编写。
如果您这样做了，那么像“UserImpl”这样“难看”的具体类名应该安全地隐藏在代码的其余部分中，这些代码可以愉快地继续使用“漂亮”的接口名。
正如另一位发帖者所说，通常更可取的做法是让接口定义功能，而不是类型。我倾向于不“实现”像“User”这样的东西，这就是为什么在这里描述的方式中“IUser”通常不是真正必要的。我经常把类看作名词，把接口看作形容词:
class Number implements Comparable{...}
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}
有时形容词没有意义，但我仍然通常使用接口来建模行为、动作、功能、属性等等……没有类型。
另外，如果你只创建一个User，并将其命名为User，那么还有IUser接口的意义何在?如果您将有几个不同类型的用户需要实现一个公共接口，那么在选择实现名称时，在接口上附加一个“I”会为您节省什么呢?
我认为一个更现实的例子是，某些类型的用户需要能够登录到特定的API。我们可以定义一个Login接口，然后有一个带有SuperUser、DefaultUser、AdminUser、AdministrativeContact等子类的“User”父类，其中一些会或不会在必要时实现Login(可登录的?)接口。
根据我的经验，“I”约定适用于旨在向类提供契约的接口，特别是当接口本身不是类的抽象概念时。
例如，在您的例子中，如果您希望拥有的唯一用户是user，那么我只希望看到IUser。如果您计划使用不同类型的用户——NoviceUser、ExpertUser等等——我希望看到一个User接口(也许还有一个实现了一些常见功能的AbstractUser类，比如get/setName())。
我还希望定义功能(Comparable、Iterable等)的接口这样命名，而不是IComparable或IIterable。
