Java 接口/实现命名约定 [英] Java Interfaces/Implementation naming convention
问题描述
你如何命名你创建的不同类/接口?有时我没有要添加到实现名称的实现信息 - 例如接口 FileHandler 和类 SqlFileHandler.
当发生这种情况时，我通常以普通"名称命名接口，例如 Truck，并将实际类命名为 TruckClass.
在这方面，您如何命名接口和类?
为您的 Interface 命名.卡车.不是 ITruck 因为它不是 ITruck 它是 Truck.
Java 中的 Interface 是一个 输入.然后你有 DumpTruck、TransferTruck、WreckerTruck、CementTruck 等实现卡车.
当您使用 Interface 代替子类时，您只需将其转换为 Truck.如List.把 I 放在前面只是 匈牙利风格符号重言式，只添加了更多内容到您的代码.
所有现代 Java IDE 都标记了接口和实现，没有这种愚蠢的符号也不行.不要将其称为 TruckClass，即 重言式和 IInterface 同义反复一样糟糕.
如果它是一个实现，它就是一个类.这条规则唯一真正的例外，而且总是有例外，可能是类似 AbstractTruck 的东西.由于只有子类会看到这一点，并且您永远不应该将其强制转换为 Abstract 类，因此它确实添加了一些关于该类是抽象的以及应该如何使用它的信息.您仍然可以想出一个比 AbstractTruck 更好的名称并使用 BaseTruck 或 DefaultTruck 代替，因为 abstract 在定义.但是由于 Abstract 类永远不应该成为任何面向公众的接口的一部分，我相信这是规则的一个可接受的例外.使构造函数protected 对跨越这个鸿沟大有帮助.
Impl 后缀也只是更多的噪音.更多的同义反复.任何不是接口的东西都是实现，甚至是部分实现的抽象类.你打算在每个 Impl 后缀吗?rel="noreferrer">课程?
Interface 是关于公共方法和属性必须支持什么的契约，它也是 Type 信息也是如此.实现 Truck 的一切都是一个 Type<Truck 的/a>.
查看 Java 标准库本身.你看到IList、ArrayListImpl、LinkedListImpl吗?不，您会看到 List 和 ArrayList 和 LinkedList.这是一个不错的 文章 关于这个确切的问题.任何这些愚蠢的前缀/后缀命名约定都违反了 DRY 原则.>
此外，如果您发现自己向对象添加了DTO、JDO、BEAN 或其他愚蠢的重复后缀，那么它们可能属于package 而不是所有这些后缀.正确打包的命名空间是自我记录的，并减少了这些构思非常糟糕的专有命名方案中所有无用的冗余信息，大多数地方甚至在内部都没有以一致的方式遵守这些方案.
如果你能想出的让你的 Class 名称唯一的就是在它后面加上 Impl，那么你需要重新考虑拥有一个 Interface> 一点.因此，当您有一个 Interface 和一个 Implementation 的情况时，该 Implementation 不是从 Interface 中唯一专门化的，您可能不需要在大多数情况下是 Interface.
然而，一般来说，为了可维护性、可测试性、模拟，提供接口是最佳实践.请参阅此答案了解更多详情.
另请参阅 Martin Fowler 撰写的关于 InterfaceImplementationPair
的这篇有趣文章How do you name different classes / interfaces you create?
Sometimes I don't have implementation information to add to the implementation name - like interface FileHandler and class SqlFileHandler.
When this happens I usually name the interface in the "normal" name, like Truck and name the actual class TruckClass.
How do you name interfaces and classes in this regard?
Name your Interface what it is. Truck. Not ITruck because it isn't an ITruck it is a Truck.
An Interface in Java is a Type. Then you have DumpTruck, TransferTruck, WreckerTruck, CementTruck, etc that implements Truck.
When you are using the Interface in place of a sub-class you just cast it to Truck. As in List<Truck>. Putting I in front is just Hungarian style notation tautology that adds nothing but more stuff to type to your code.
All modern Java IDE's mark Interfaces and Implementations and what not without this silly notation. Don't call it TruckClass that is tautology just as bad as the IInterface tautology.
If it is an implementation it is a class. The only real exception to this rule, and there are always exceptions, could be something like AbstractTruck. Since only the sub-classes will ever see this and you should never cast to an Abstract class it does add some information that the class is abstract and to how it should be used. You could still come up with a better name than AbstractTruck and use BaseTruck or DefaultTruck instead since the abstract is in the definition. But since Abstract classes should never be part of any public facing interface I believe it is an acceptable exception to the rule. Making the constructors protected goes a long way to crossing this divide.
And the Impl suffix is just more noise as well. More tautology. Anything that isn't an interface is an implementation, even abstract classes which are partial implementations. Are you going to put that silly Impl suffix on every name of every Class?
The Interface is a contract on what the public methods and properties have to support, it is also Type information as well. Everything that implements Truck is a Type of Truck.
Look to the Java standard library itself. Do you see IList, ArrayListImpl, LinkedListImpl? No, you see List and ArrayList, and LinkedList. Here is a nice article about this exact question. Any of these silly prefix/suffix naming conventions all violate the DRY principle as well.
Also, if you find yourself adding DTO, JDO, BEAN or other silly repetitive suffixes to objects then they probably belong in a package instead of all those suffixes. Properly packaged namespaces are self documenting and reduce all the useless redundant information in these really poorly conceived proprietary naming schemes that most places don't even internally adhere to in a consistent manner.
If all you can come up with to make your Class name unique is suffixing it with Impl, then you need to rethink having an Interface at all. So when you have a situation where you have an Interface and a single Implementation that is not uniquely specialized from the Interface you probably don't need the Interface in most cases.
However, in general for maintainability, testability, mocking, it's best practice to provide interfaces. See this answer for more details.
Also Refer this interesting article by Martin Fowler on this topic of InterfaceImplementationPair
这篇关于Java 接口/实现命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
