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

List -“概念性”对象的接口 数组列表接口的具体实现 接口的具体实现 AbstractList——抽象的“部分”实现，以帮助自定义实现

我曾经在AWT事件/监听器/适配器范例之后做同样的事情来建模我的事件类。

TruckClass听起来像是Truck的一个类，我认为推荐的解决方案是添加Impl后缀。在我看来，最好的解决方案是在实现名称中包含一些信息，在特定的实现中发生了什么(就像我们有List接口和实现:ArrayList或LinkedList)，但有时你只有一个实现，并且由于远程使用(例如)必须有接口，那么(如开头提到的)Impl是解决方案。

有些人不喜欢这样，它更像是。net的约定而不是Java，但是你可以用大写的I前缀来命名你的接口，例如:

IProductRepository - interface
ProductRepository, SqlProductRepository, etc. - implementations

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

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

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

List -“概念性”对象的接口 数组列表接口的具体实现 接口的具体实现 AbstractList——抽象的“部分”实现，以帮助自定义实现

我曾经在AWT事件/监听器/适配器范例之后做同样的事情来建模我的事件类。

我在这里看到的回答表明，如果你只有一个实现，那么你就不需要接口。这违背了依赖注入/控制反转原则(不要给我们打电话，我们会给你打电话!)。

So yes, there are situations in which you wish to simplify your code and make it easily testable by relying on injected interface implementations (which may also be proxied - your code doesn't know!). Even if you only have two implementations - one a Mock for testing, and one that gets injected into the actual production code - this doesn't make having an interface superfluous. A well documented interface establishes a contract, which can also be maintained by a strict mock implementation for testing.

事实上，您可以建立测试，让模拟实现最严格的接口契约(为不应该为空的参数抛出异常，等等)并在测试中捕获错误，在生产代码中使用更有效的实现(不检查不应该为空的参数是否为空，因为模拟在测试中抛出异常，并且由于在这些测试后修复了代码，您知道参数不为空)。

依赖注入/IOC对于新手来说很难理解，但是一旦你理解了它的潜力，你就会想要在任何地方都使用它，你会发现自己一直在做接口——即使只有一个(实际的生产)实现。

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

我也更喜欢“基类(InterfaceName)”而不是“抽象(InterfaceName)”，因为在某些情况下，你希望你的基类以后成为可实例化的，但现在你被“抽象(InterfaceName)”这个名字卡住了，这迫使你重命名类，可能会造成一些小混乱-但如果它总是Base(InterfaceName)，删除抽象修饰符不会改变类是什么。

标准的c#约定(在Java中也很好用)是给所有接口加上一个I前缀，所以你的文件处理程序接口将是IFileHandler，你的卡车接口将是ITruck。它是一致的，并且很容易区分接口和类。