Java中的接口命名
大多数OO语言的接口名称都以大写的I开头，为什么Java不这样做呢？不遵守该公约的理由是什么？
为了说明我的意思，如果我想拥有一个用户界面和一个用户实现，那么在Java中有两种选择：
- 类=用户，接口= UserInterface
- 类= UserImpl，接口=用户
在大多数语言中：
- 类=用户，接口= IUser
现在，你可能会争辩说，你总是可以为用户实现选择一个最具描述性的名称，问题就消失了，但是Java将POJO方法推向了事物，并且大多数IOC容器广泛使用DynamicProxies。这两件事在一起意味着你将通过单个POJO实现拥有很多接口。
因此，我想我的问题可以归结为：“是否值得遵循更广泛的接口命名约定，尤其是考虑到Java框架的发展方向？”
问题答案：
我不想在接口上使用前缀：
- 前缀会损害可读性。
- 在客户端中使用接口是进行编程的最佳标准方法，因此接口名称应尽可能简短和令人愉快。实施类应该更丑陋以阻止其使用。
- 当从抽象类更改为接口时，带前缀的编码约定意味着重命名该类的所有出现—不好！
-
问题内容： 我在一个Java Web应用程序上工作，该应用程序使用Spring进行依赖注入，并使用JMock来模拟单元测试中的这些依赖。 目前，在如何命名所使用的某些接口方面，我们的团队还处于不同意见。命名域中具有多个实现的接口没有问题，这很简单。但是，当涉及到我们只有一个实现并且打算将来仅拥有一个实现的接口时，我们遇到了麻烦。 我们拥有此类接口的原因纯粹是为了模拟，例如，我们有在单元测试中模拟的
-
问题内容： 一位同事问我有关Java API中的类的问题。 按照标准，我确实理解，每个* able结尾的单词都是java API中的接口。有一个关于使用诸如接口名称之类的行业标准。因此，我在不知不觉中告诉他有关Java世界中所有异常和错误类型的基本接口。然后，他向我展示了此类的Java文件。 我的问题： 为什么Java人选择此名称作为类。我认为默认情况下应该是接口？ 这是使用* able单词作为界
-
问题内容： 如何命名你创建的不同类/接口？有时我没有实现信息要添加到实现名称中，例如接口和类。 发生这种情况时，我通常使用“普通”名称来命名接口，例如Truck并命名实际的类。 你在这方面如何命名接口和类？ 问题答案： 命名你的名字。。不是因为它不是一个而是一个。 中的 是。然后你有，，等那个。 当你使用Interface代替子类时，只需将其转换为即可Truck。就像在List 。把I前面的只是匈
-
为什么它这样做，它有一个更好的做法？在sub接口中实现方法有什么区别吗？
-
问题内容： 有人可以向我解释一下，编译器在第一次强制转换时不会抱怨，而在第二次强制转换时会抱怨吗？ 问题答案： 在和一起使用时，您告诉编译器该对象的类实际上是其声明类型的子类，并且该子类实现。 该班是 最后的 ，所以不可能是一个子类的实例：编译器知道你在说谎。但是不是最终的，所以 可以 是该Implements 的子类型的实例。 如果您使用final，编译器也会抱怨：
-
我被告知Java中的标记接口是一个空接口，用于向编译器或JVM发出信号，表明实现此接口的类的对象必须以特殊方式处理，如序列化、克隆等。 但是最近我了解到，它实际上与编译器或JVM无关。例如，在< code>Serializable接口的情况下，< code>ObjectOutputStream的方法< code>writeObject(Object)执行类似于< code > instance o