我正在开发一个 Java Web 应用程序，该应用程序使用 Spring 进行依赖项注入，并使用 JMock 在我们的单元测试中模拟这些依赖项。
目前，我们的团队对于如何命名我们使用的某些接口有一些不同的意见。我们对命名域中具有多个实现的接口没有任何问题，这很简单。然而，当涉及到我们只有一种实现并且打算在未来只有一种实现的接口时，我们遇到了障碍。
我们拥有这样的接口的原因纯粹是为了模拟，例如，我们有在单元测试中模拟的服务和存储库，这些服务将被命名为“DocumentMappingService”，或者存储库将被命名为“EmployeeRepository”。目前，有些人只是在关联的接口名称前加上“I”前缀，即“IDocumentMappingService”和“IEmployeeRepository”。其他人按照我上面的方式命名接口，然后在实现类的接口名称后面附加“Impl”。
第三“派”认为这两种选择都很糟糕。查看诸如著名的“以测试为指导的增长的面向对象软件”之类的文献，会导致人们相信前面提到的两种选择都很糟糕，并且接口名称应该清楚地定义契约和实现类名称应明确说明该合同是如何实施的。不过，我们发现在我上面提到的情况下很难做到这一点。
我希望有人以前遇到过类似的问题，并提出一些建议，告诉我哪个选项是最好的以及为什么。另外，如果您认为“I”和“Impl”选项都很差，那么请建议一个特定的替代约定。
这里没有“一个”正确答案。命名是很主观的，但最重要的是它应该是持续的整个代码库。我只想为您添加（到@fge的答案）一些更多选项：
-
使接口更加通用。
EmployeeRepository implements Repository
DocumentMappingService implements MappingService
-
调用您的单一实现“默认”.
DefaultEmployeeRepository implements EmployeeRepository
DefaultDocumentMappingService implements DocumentMappingService
-
将您的基本实现（如果有时扩展）称为“支持”.
EmployeeRepositorySupport implements EmployeeRepository
DocumentMappingServiceSupport implements DocumentMappingService
我在使用时经常遇到这些命名约定Spring框架.
Edit : In response to user
nyxz's comment about the
-Base or
Base- convention.
就像我之前说过的，命名是主观的，使用Base命名法本身。但是，就我个人而言，我不喜欢使用它。原因如下：
如果您的实现主要是直接使用，那么实例化类的代码会留下破坏 OOP 层次结构的印象。也许应该实例化一个特定的派生类。
如果您的实现主要是扩展自，那么这个词Base在某种程度上变得多余。您是从它扩展的，所以它当然是一个基类。呃！
The 2nd点主要适用于项目中的外围类。当您发布要在其他项目中使用和扩展的框架或库时提供的扩展点。
另一方面，使用Base术语适用于框架内部的类，这些类从其他外围类中提取出通用功能。由于这些类不应该直接实例化，因此它们被标记为abstract，这符合1st point.
这是Adapter以Android框架的层次结构为例：
-
接口层次结构。
public interface Adapter
public interface ListAdapter extends Adapter
public interface SpinnerAdapter extends Adapter
-
The abstract Base分解出常见行为和接口实现的类。
public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter
-
大多数由 Android 应用程序实例化但有时扩展的外围类。
public class SimpleAdapter extends BaseAdapter implements Filterable
public class ArrayAdapter<T> extends BaseAdapter implements Filterable
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
