Java接口/实现命名约定

#1 楼

将其命名为Interface。 Truck。不是ITruck，因为它不是ITruck，而是Truck。

Java中的Interface是类型。那么你有DumpTruck，TransferTruck，WreckerTruck，CementTruck等等implement Truck。

使用Interface代替子类时，只需将其转换为Truck即可。如在List<Truck>中。将I放在前面只是匈牙利语风格的重言式，只会在代码中添加更多内容。

所有现代Java IDE的标记接口和实现，如果没有这种愚蠢的表示法，那将是什么。不要称它为重言式TruckClass就像IInterface重言式一样糟糕。

如果是实现，则为类。该规则唯一真正的例外（总是存在例外）可能类似于AbstractTruck。由于只有子类会看到这种情况，并且您永远都不应转换为Abstract类，因此它确实会添加一些信息，说明该类是抽象的，以及如何使用它。您仍然可以使用比AbstractTruck更好的名称，而改用BaseTruck或DefaultTruck，因为定义中包含abstract。但是，由于Abstract类不应成为任何面向公众的接口的一部分，因此我认为这是该规则的可接受的例外。使构造函数protected跨越了这一鸿沟。

Impl后缀也带来了更多噪音。重言式。任何不是接口的东西都是实现，甚至是部分实现的抽象类。您是否要在每个班级的每个名称上都添加一个愚蠢的Impl后缀？

Interface是有关公共方法和属性必须支持的合同，它也是Type信息。实现Truck的所有内容都是Truck的类型。

查看Java标准库本身。您看到IList，ArrayListImpl，LinkedListImpl吗？不，您看到List和ArrayList以及LinkedList。这是一篇关于这个确切问题的好文章。所有这些愚蠢的前缀/后缀命名约定都违反了DRY原则。而不是所有这些后缀。正确包装的名称空间可以自我记录，并减少这些真正构思不当的专有命名方案中所有无用的冗余信息，而大多数地方甚至在内部都不以一致的方式坚持这些专有命名方案。

如果想让DTO的名称唯一的原因是给JDO加后缀，那么您就需要重新考虑使用BEAN。因此，当您遇到一个Class和一个不是从Impl唯一专用的Interface的情况时，您可能不需要Interface。

#2 楼

我在这里看到的答案表明，如果只有一个实现，则不需要接口。这与“依赖注入/控制反转”原理相违背（不要打电话给我们，我们会打电话给您！）。

所以是的，在某些情况下，您希望简化代码，并依靠注入的接口实现轻松地对其进行测试（也可能是代理-您的代码不知道！）。即使您只有两种实现-一种用于测试的Mock，另一种被注入到实际的生产代码中-这也不会使接口变得多余。记录良好的界面可建立合同，也可以通过严格的模拟实施进行维护以进行测试。

实际上，您可以建立测试，使模拟程序执行最严格的接口协定（为不应为null的参数抛出异常等），并在测试中使用更有效的实现捕获错误。生产代码（例如，由于模拟在测试中引发了异常，因此不检查不应该为null的参数是否为null，例如，由于在这些测试之后修复了代码，因此您知道参数不为null）。

对于新手来说，依赖注入/ IOC可能很难掌握，但是一旦您了解了它的潜力，便会想在各处使用它，并且会发现自己一直在建立接口-即使只有这样是一个（实际生产的）实现。

对于这个实现（您可以推断，并且您是对的，我相信用于测试的模拟应该称为Mock（InterfaceName）），我更喜欢名称Default（InterfaceName）。如果出现更具体的实现，则可以适当地命名。这也避免了我特别不喜欢的Impl后缀（如果它不是一个抽象类，当然，它是一个“ impl”！）。

我也更喜欢“ Base（InterfaceName）”而不是“ Abstract（InterfaceName）”，因为在某些情况下，您希望您的基类稍后可以实例化，但是现在您的名称仍然是“ Abstract（InterfaceName）” ，这会迫使您重命名该类，可能会引起一些轻微的混乱-但是，如果始终是Base（InterfaceName），则删除abstract修饰符不会更改该类的名称。

#3 楼

接口的名称应描述接口代表的抽象概念。任何实现类都应该具有某种特定的特征，可以用来为其赋予一个更特定的名称。

如果只有一个实现类，并且您想不出任何使其具有特定性的东西（想要将其命名为-Impl），则似乎根本没有理由拥有一个接口。

#4 楼

我倾向于遵循Java Core / Sun建立的伪约定，例如在Collections类中：



List-“概念”对象的接口

ArrayList-接口的具体实现

LinkedList-接口的具体实现

AbstractList-抽象的“部分”实现，以帮助实现自定义实现

我曾经在AWT事件之后做同样的事情来为事件类建模/ Listener / Adapter范例。

#5 楼

标准的C＃约定（在Java中也足够好用）是为所有接口添加I前缀-因此您的文件处理程序接口将为IFileHandler，而卡车接口将为ITruck。它是一致的，并且可以很容易地从类中区分接口。

#6 楼

我喜欢表示接口描述的协定的接口名称，例如“ Comparable”或“ Serializable”。像“卡车”这样的名词并不能真正描述卡车的特质-卡车的能力是什么？

关于约定：我从事的项目中每个接口都以“ I”开头；尽管这与Java约定有些不同，但它使查找接口非常容易。除此之外，“ Impl”后缀是一个合理的默认名称。

#7 楼

有些人不喜欢它，它比Java更像.NET约定，但是您可以使用大写的I前缀来命名接口，例如：

IProductRepository - interface
ProductRepository, SqlProductRepository, etc. - implementations

反对这种命名约定的人可能会争辩说，您不必关心您是在代码中使用接口还是对象，但是我发现即时更容易阅读和理解。

我不会以“ Class”后缀来命名实现类。这可能会导致混乱，因为您实际上可以在代码中使用“类”（即Type）对象，但是在这种情况下，您不是在使用类对象，而只是在使用普通的对象。

#8 楼

我使用两种约定：

如果接口是众所周知的模式（例如Service，DAO）的特定实例，则可能不需要全部使用“ I”（例如UserService，AuditService，UserDao）在没有“ I”的情况下可以正常工作，因为后缀确定了元模式。但是，如果您一次或两次执行某些操作（通常用于回调模式），那么它将有所帮助区别于类（例如IAsynchCallbackHandler，IUpdateListener，IComputeDrone）。这些是供内部使用而设计的专用接口，有时IInterface会引起人们对操作数实际上是接口这一事实的关注，因此乍一看就很清楚。

在其他情况下，您可以使用I，以避免与其他常见的具体类（ISubject，IPrincipal与Subject或Principal）冲突。

#9 楼

TruckClass听起来像是Truck的一类，我认为建议的解决方案是添加Impl后缀。我认为最好的解决方案是在实现名称中包含一些信息，该信息具体实现时会发生什么情况（例如List接口和实现：ArrayList或LinkedList），但是有时您只有一个实现并且必须有接口到远程使用（例如），然后（如开头所述）Impl是解决方案。