Почему должен интерфейс для класса Java быть предпочтенным?

Это предпочтено, потому что Вы разъединяете свой код от реализации списка. Используя интерфейс позволяет Вам легко изменить реализацию, ArrayList в этом случае, к другой реализации списка, не изменяя ни одной остальной части кода, пока это только использует методы, определенные в Списке.

В целом я соглашаюсь, что разъединение интерфейса от реализации является хорошей вещью и сделает Ваш код легче поддержать.

существуют, однако, исключения, которые необходимо рассмотреть. Доступ к объектам через интерфейсы добавляет дополнительный слой косвенности, которая сделает Ваш код медленнее.

Для интереса я выполнил эксперимент, который генерировал десять миллиардов последовательных доступов к 1 миллиону длин ArrayList. На моем MacBook на 2.4 ГГц, получая доступ к ArrayList через интерфейс List занял 2,10 секунды в среднем, при объявлении его типа ArrayList, потребовалось в среднем 1,67 секунды.

, Если Вы работаете с большими списками, глубоко во внутреннем цикле или часто вызываемой функции, тогда это - что-то для рассмотрения.

ArrayList и LinkedList являются двумя реализациями Списка, который является заказанным набором объектов. Логически-мудрый не имеет значения при использовании ArrayList или LinkedList таким образом, Вы не должны вынуждать тип быть этим.

Это контрастирует с, говорят, Набор и Список, которые являются разными вещами (Список подразумевает сортировку, Набор не делает).

Свойства Ваших классов/интерфейсов должны быть представлены через интерфейсы, потому что это дает Вашим классам контракт поведения для использования, независимо от реализации.

Однако...

В локальных объявлениях переменных, имеет мало смысла делать это:

public void someMethod() {
List theList = new ArrayList();
//do stuff with the list
}

, Если это - локальная переменная, просто используйте тип. Это все еще неявно upcastable к своему соответствующему интерфейсу, и Ваши методы должны, надо надеяться, принять интерфейсные типы для его аргументов, но для локальных переменных, имеет общий смысл использовать тип реализации в качестве контейнера, на всякий случай Вам действительно нужна определенная для реализации функциональность.

Даже для локальных переменных, с помощью интерфейса по реальному классу помогает. Можно закончить тем, что назвали метод, который является вне интерфейса, и затем трудно изменить реализацию Списка при необходимости. Кроме того, лучше использовать наименее определенный класс или интерфейс в объявлении. Если порядок элемента не имеет значения, используйте Набор вместо Списка. Это дает Вашему коду максимальную гибкость.

В целом для Вашей строки кода не имеет смысла беспокоиться интерфейсами. Но, если мы говорим о API существует действительно серьезное основание. Я добрался, маленький класс

class Counter {
    static int sizeOf(List<?> items) {
        return items.size();
    }
}

В этом случае является использованием требуемого интерфейса. Поскольку я хочу считать размер каждое возможное реализация включая мое собственное. class MyList extends AbstractList<String>....