类/接口“默认”实现的命名规范

Question

我在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后缀的方式基本相同：提供基本/默认实现。我可以尝试一个名字，暗示这是由内存存储支持的Foo（例如Bar），但这总是会涵盖所有BasicFoo中的功能。我也不确定是否应该放弃接口并直接暴露实现，因为接口提供了额外的灵活性和解耦。对于处理此场景的更好方式或逻辑命名约定的想法如何？

- Tyson

Answer 1

在Java世界中，常见的一种模式是将抽象、不完整的实现命名为AbstractSomething，例如AbstractList或AbstractButton。接口和抽象类均向客户端公开。这样做的想法是，抽象类在使用API时充当起点。这对于定义许多方法和复杂契约的接口非常有用，例如java.util.List。接口的大多数方法都是基于客户端必须提供的最小抽象方法集实现的。

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

- Joni