Api “类/接口的命名约定”；“违约”；实施

我在StackOverflow上看到过类/接口命名问题，也读过很多关于这个主题的其他问题，但我有一个相关的问题，我不确定这些地方是否有答案。我倾向于讨厌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;
    }
}

实际上，我倾向于用Basic作为实现名称的前缀，但我所做的实际上正是一些人使用Impl后缀的目的：提供基本/默认实现。我可以尝试一个名称，它意味着它是一个由内存存储（例如Bar）支持的Foo，但它总是捕获BasicFoo中的所有功能。我也不认为我应该抛弃接口，直接公开实现，因为接口提供了额外的灵活性和解耦

---

如何更好地处理这种情况，或者采用一种逻辑命名约定？

Java世界中的一种常见模式称为抽象的、不完整的实现

AbstractSomething

；例如或。接口和抽象类都向客户机公开。这背后的想法是，当使用API时，抽象类是一个起点。这对于定义许多方法和复杂契约的接口尤其有用，例如java.util.List。接口的大多数方法都是根据客户机必须提供的一组最小的抽象方法来实现的

---

例如，要实现基于

AbstractList

的列表，您只需提供

get（index）

和

size（）

方法的实现。所有其他操作-迭代器、

indexOf

、

subList

、

hashCode

…-最后，委托给这两个人

酷，这是有道理的，正是我想要的。谢谢