在c#中是这样的

public class AdminForumUser : UserBase, IUser

Java会说

public class AdminForumUser extends User implements ForumUserInterface

正因为如此，我认为在java中，约定对于接口来说并没有那么重要，因为继承和接口实现之间有明显的区别。我会说选择任何你喜欢的命名约定，只要你是一致的，并使用一些东西向人们展示这些是接口。我已经好几年没有使用java了，但是所有的接口都在它们自己的目录下，这是惯例。从来没有什么问题。

这两者真的有区别吗:

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

根据我的经验，“I”约定适用于旨在向类提供契约的接口，特别是当接口本身不是类的抽象概念时。

例如，在您的例子中，如果您希望拥有的唯一用户是user，那么我只希望看到IUser。如果您计划使用不同类型的用户——NoviceUser、ExpertUser等等——我希望看到一个User接口(也许还有一个实现了一些常见功能的AbstractUser类，比如get/setName())。

我还希望定义功能(Comparable、Iterable等)的接口这样命名，而不是IComparable或IIterable。

正如另一位发帖者所说，通常更可取的做法是让接口定义功能，而不是类型。我倾向于不“实现”像“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。你的界面现在被称为User。也许你有一个UserProdImpl和一个UserTestImpl。如果你的应用程序设计得很好，每个类(除了实例化User的类)都不会改变，不会注意到它们突然被传递了一个接口。

接口用户实现UserImpl。