4

我已经在 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 中的所有功能。我也不相信我应该抛弃接口并直接公开实现，因为接口提供了额外的灵活性和解耦。

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

4

1 回答 1

3

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

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

于 2013-03-24T00:29:04.200 回答