类/接口“默认”实现的命名约定

Question

我见过thecanonical在StackOverflow上的类/接口命名问题，并阅读了很多关于这个主题的其他opinions，但我有一个相关的问题，我不知道是在任何这些地方回答。我倾向于厌恶IInterface或ClassImpl命名约定，因为并同意我链接的问题和文章的答案中的观点：它们是不必要的（对于现代IDE），使代码难以阅读，并且许多情况下需要使用这些命名模式之一似乎意味着不正确的设计。

但是，我经常碰到一个场景，我有一个我想要作为API的一部分公开的接口（通常在一个单独的包中），然后创建接口的抽象实现以包含一些常用功能我期望大多数（但不是全部）具体的实现来源于。例如：

public interface Foo { 
    public String getBar(); 
} 

public abstract class BasicFoo implements Bar { 
    private String bar; 

    @Override 
    public String getBar() { 
     return bar; 
    } 
} 

在实践中我倾向于使用基本的前缀实现的名字，但我在做什么本质上是一些人正在使用正是为默认地将Impl后缀：提供基本/默认实现。我可以尝试一个名称，暗示它是内存存储支持的Foo（例如Bar），但它总是捕获BasicFoo中的所有功能。我也不相信我应该抛出接口并直接公开实现，因为接口提供了额外的灵活性和解耦。

有更好的方法来处理这种情况或逻辑命名约定的想法？

Answer 1

Java世界中常见的模式是调用抽象的，不完整的实现AbstractSomething;例如AbstractList或AbstractButton。接口和抽象类都暴露给客户端。这背后的想法是抽象类作为使用API​​的起点。这对于定义许多方法和复杂合约的接口尤其有用，例如java.util.List。接口的大部分方法都是以客户端必须提供的最小抽象方法集来实现的。

例如，要实施基于AbstractList的列表，您只需提供get(index)和size()方法的实施方案。所有其他操作 - 迭代器，indexOf,subList,hashCode ... - 最后委托给这两个。