大多数面向对象语言的接口名称都以大写的I开头，为什么Java不这样做呢?不遵循这一惯例的理由是什么?
为了证明我的意思，如果我想有一个用户界面和一个用户实现，我在Java中有两个选择:
类=用户，接口= UserInterface 类= UserImpl，接口=用户
在大多数语言中:
类=用户，接口= IUser
现在，您可能会争辩说，您总是可以为用户实现选择一个最具描述性的名称，这样问题就解决了，但Java正在推动POJO方法，大多数IOC容器广泛使用dynamicproxy。这两件事加在一起意味着您将使用单个POJO实现拥有许多接口。
所以，我想我的问题可以归结为:“是否值得遵循更广泛的接口命名约定，尤其是考虑到Java框架的发展方向?”
当前回答
我不喜欢在接口上使用前缀:
前缀损害了可读性。 在客户端中使用接口是编程的标准最佳方式，因此接口名称应该尽可能简短而美观。实现类应该更加丑陋，以阻止它们的使用。 当从抽象类更改为接口时，前缀为I的编码惯例意味着重命名类的所有出现项——这不好!
其他回答
鲍勃·李曾在一次演讲中说:
接口的意义是什么，如果你 只有一个实现。
因此，您从一个实现开始，即没有接口。 稍后，您决定这里需要一个接口，因此您将类转换为接口。
那么很明显:你原来的类叫User。你的界面现在被称为User。也许你有一个UserProdImpl和一个UserTestImpl。如果你的应用程序设计得很好，每个类(除了实例化User的类)都不会改变，不会注意到它们突然被传递了一个接口。
接口用户实现UserImpl。
在c#中是这样的
public class AdminForumUser : UserBase, IUser
Java会说
public class AdminForumUser extends User implements ForumUserInterface
正因为如此，我认为在java中，约定对于接口来说并没有那么重要，因为继承和接口实现之间有明显的区别。我会说选择任何你喜欢的命名约定，只要你是一致的，并使用一些东西向人们展示这些是接口。我已经好几年没有使用java了，但是所有的接口都在它们自己的目录下，这是惯例。从来没有什么问题。
还有另一种约定，被包括Spring在内的许多开源项目所使用。
interface User {
}
class DefaultUser implements User {
}
class AnotherClassOfUser implements User {
}
我个人不喜欢“I”前缀，原因很简单，它是一个可选的约定。所以，如果我采用这种IOPConnection意味着接口的IOPConnection?如果类没有“I”前缀，那么我是否知道它不是一个接口呢?这里的答案是否定的，因为约定并不总是遵循的，监管它们将创建更多的工作，而约定本身节省了。
根据我的经验，“I”约定适用于旨在向类提供契约的接口，特别是当接口本身不是类的抽象概念时。
例如，在您的例子中，如果您希望拥有的唯一用户是user，那么我只希望看到IUser。如果您计划使用不同类型的用户——NoviceUser、ExpertUser等等——我希望看到一个User接口(也许还有一个实现了一些常见功能的AbstractUser类，比如get/setName())。
我还希望定义功能(Comparable、Iterable等)的接口这样命名，而不是IComparable或IIterable。
这两者真的有区别吗:
class User implements IUser
and
class UserImpl implements User
如果我们讨论的是命名惯例?
就我个人而言，我不喜欢在接口之前使用I，因为我想对接口进行编码，我认为这在命名约定方面更重要。如果调用接口IUser，那么该类的每个消费者都需要知道它是IUser。如果调用类UserImpl，那么只有类和DI容器知道Impl部分，而使用者只知道他们正在使用User。
然后，我被迫使用Impl的时候，因为一个更好的名字本身没有出现，因为实现是根据实现命名的，因为这是它的重要之处，例如。
class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO
