java - 接口(interface)编程很棒，我 100% 同意，但它总是可行吗？

Question

这是一个例子:

具体的实现可能有一些特定的行为，比如 ArrayList 的实现有 ensureCapacity()，它不适用于 LinkedList。

//programming to interface not implementation
List list = new ArrayList();
list.add("hi");
list.add("hello");

// now I need to use some method from ArrayList e.g. ensureCapacity() 
list.ensureCapacity(); // can't as list is List with no ensureCapacity()

经过编辑以包含更多详细信息:

第二个示例场景:

List list=new LinkedList();
Iterator li=list.listIterator();// Program to interface rule
li.add("Hi");// NOT allowed as add() is part of ListIterator

Q1。如果我们要“编程到接口(interface)”，ListIterator 和 ArrayList 中的“add()”等特定方法有什么必要？

Q2。 “针对接口(interface)编程”是否意味着“尽可能多地应用这个概念，但不能总是”？

Q3。使用 ListIterator 而不是 Iterator 会更好吗？

Answer 1

在您的情况下，使用接口(interface) (List) 而不是类 (ArrayList) 的想法是您并不真正关心实现。在创建时你选择一个类型(或者由谁提供列表给你)之后，你不必担心类型，你的代码将适用于所有 List。

然而，在您的情况下，您使用了一种特定于 ArrayList 的机制。如果没有，您的代码也可以正常工作，因为 ensureCapacity() 只是一种告诉 ArrayList 如果一次性保留其容量(而不是稳步上升)。您现在有以下选择:

1. 不要进行优化，在大多数情况下您不需要它，因为 ArrayList 会在没有提示的情况下做得很好。
2. 要求 ArrayList 使其使用起来更高效，但灵 active 较低，因为即使在性能无关紧要的情况下，您的代码也只接受 ArrayList。
3. 最后，您可以使用 instanceof ArrayList，并且只有在提供 ArrayList 时才进行优化。这不是很干净，但有时您必须这样做才能为您的类的用户提供最佳体验。如果您发布了广泛使用的 API，就会出现这种情况。

在大多数情况下，第 1 项是您的最佳选择。如果此代码在许多情况下未被使用，但对您知道可以(或将)始终是 ArrayList 的内容进行操作，因为它是在相同的类/方法中创建的并且您需要性能项 2 是一个不错的选择。

所以结论是:不，这并不总是可能的，也不是可取的。其背后的想法是您使用尽可能通用的接口(interface)(或父类(super class))，为您的代码用户提供最大的自由。

编辑:请注意，ensureCapacity 实际上只需要包含数百万项的列表，因为 ArrayList 会随着增量的增加而扩展。在大多数情况下，当它需要更多空间时，它至少会将内部数组加倍，如下所示(请注意，这是来自 Java 8 中的 Oracle 实现):

private void grow(int minCapacity) {
    // overflow-conscious code
    int oldCapacity = elementData.length;
    int newCapacity = oldCapacity + (oldCapacity >> 1); // This more than doubles the size
    if (newCapacity - minCapacity < 0)
        newCapacity = minCapacity;
    if (newCapacity - MAX_ARRAY_SIZE > 0)
        newCapacity = hugeCapacity(minCapacity);
    // minCapacity is usually close to size, so this is a win:
    elementData = Arrays.copyOf(elementData, newCapacity);
}