Почему стандартные и статические методы были добавлены к интерфейсам в Java 8, когда у нас уже были абстрактные классы?

В Java 8 интерфейсы могут содержать реализованные методы, статические методы и так называемые методы «по умолчанию» (которые классам реализации не нужно переопределять).

На мой (возможно, наивный) взгляд, не было необходимости нарушать подобные интерфейсы. Интерфейсы всегда были контрактом, который вы должны выполнить, и это очень простая и чистая концепция. Теперь это смесь нескольких вещей. По моему мнению:

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

Короче говоря:

До Java 8:

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

После Java 8:

• Практически нет разницы между интерфейсом и абстрактным классом (кроме множественного наследования). На самом деле вы можете эмулировать обычный класс с интерфейсом.
• При программировании реализаций программисты могут забыть переопределить методы по умолчанию.
• Существует ошибка компиляции, если класс пытается реализовать два или более интерфейсов, имеющих метод по умолчанию с одной и той же сигнатурой.
• Добавляя метод по умолчанию к интерфейсу, каждый реализующий класс автоматически наследует это поведение. Некоторые из этих классов, возможно, не были разработаны с учетом этой новой функциональности, и это может вызвать проблемы. Например, если кто-то добавляет новый метод default void foo()по умолчанию к интерфейсу Ix, класс, Cxреализующий Ixи имеющий закрытый fooметод с той же сигнатурой, не компилируется.

Каковы основные причины таких серьезных изменений и какие новые преимущества (если таковые имеются) они добавляют?

Хороший мотивирующий пример для методов по умолчанию находится в стандартной библиотеке Java, где у вас теперь есть

list.sort(ordering);

вместо

Collections.sort(list, ordering);

Я не думаю, что они могли бы сделать это иначе без более чем одной идентичной реализации List.sort.

Правильный ответ на самом деле находится в документации Java , которая гласит:

[d] методы efault позволяют вам добавлять новые функциональные возможности к интерфейсам ваших библиотек и обеспечивать двоичную совместимость с кодом, написанным для более старых версий этих интерфейсов.

Это было давним источником боли в Java, потому что интерфейсы, как правило, невозможно развивать после того, как они были обнародованы. (Содержание в документации относится к статье, на которую вы ссылались в комментарии: Эволюция интерфейса с помощью методов виртуального расширения .) Кроме того, быстрое внедрение новых функций (например, лямбда-выражений и новых потоковых API) может быть сделано только путем расширения существующие интерфейсы коллекций и предоставление реализаций по умолчанию. Нарушение бинарной совместимости или внедрение новых API означало бы, что пройдет несколько лет, прежде чем наиболее важные функции Java 8 станут широко использоваться.

Причина, по которой статические методы допускаются в интерфейсах, снова раскрывается в документации: [t] он упрощает организацию вспомогательных методов в ваших библиотеках; вы можете хранить статические методы, специфичные для интерфейса, в том же интерфейсе, а не в отдельном классе. Другими словами, статические служебные классы, такие как, java.util.Collectionsтеперь (в конечном итоге) можно считать анти-паттерном, вообще (конечно, не всегда ). Я предполагаю, что добавление поддержки этого поведения было тривиальным, как только были реализованы методы виртуального расширения, иначе это, вероятно, не было бы сделано.

На аналогичном замечании пример того, как эти новые функции могут быть полезны, - рассмотреть один класс, который недавно меня раздражал java.util.UUID. На самом деле он не обеспечивает поддержку типов UUID 1, 2 или 5, и его нельзя легко изменить для этого. Он также застрял с предопределенным генератором случайных чисел, который нельзя переопределить. Реализация кода для неподдерживаемых типов UUID требует либо прямой зависимости от стороннего API, а не интерфейса, либо поддержки кода преобразования и затрат на дополнительную сборку мусора. С помощью статических методов UUIDможно было бы вместо этого определить интерфейс, что позволило бы реализовать сторонние реализации отсутствующих элементов. (Если бы UUIDизначально он был определен как интерфейс, у нас, вероятно, был бы какой-то неуклюжийUuidUtil класс со статическими методами, что тоже было бы ужасно.) Многие из основных API-интерфейсов Java деградируют из-за того, что не основываются на интерфейсах, но в Java 8 количество оправданий для такого плохого поведения, к счастью, уменьшилось.

Неправильно говорить, что здесь [t] практически нет разницы между интерфейсом и абстрактным классом , потому что абстрактные классы могут иметь состояние (то есть объявлять поля), а интерфейсы - нет. Поэтому он не эквивалентен множественному наследованию или даже наследованию в смешанном стиле. Правильные миксины (такие как черты Groovy 2.3 ) имеют доступ к состоянию. (Groovy также поддерживает статические методы расширения.)

По моему мнению, не очень хорошая идея следовать примеру Довала . Интерфейс должен определять контракт, но не должен обеспечивать выполнение контракта. (В любом случае, не в Java.) Правильная проверка реализации является обязанностью набора тестов или другого инструмента. Определение контрактов может быть сделано с помощью аннотаций, и OVal является хорошим примером, но я не знаю, поддерживает ли он ограничения, определенные на интерфейсах. Такая система возможна, даже если она не существует в настоящее время. (Стратегии включают настройку во время компиляции javacчерез процессор аннотацийAPI и генерация байт-кода во время выполнения.) В идеале, контракты должны выполняться во время компиляции, а в худшем случае - с использованием набора тестов, но я понимаю, что принудительное выполнение во время выполнения не одобряется. Еще одним интересным инструментом, который может помочь при программировании контрактов в Java, является Checker Framework .

Потому что вы можете наследовать только один класс. Если у вас есть два интерфейса, реализации которых достаточно сложны, и вам нужен абстрактный базовый класс, эти два интерфейса на практике взаимоисключающие.

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

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

public interface Stack<T> {
    boolean isEmpty();

    T pop() throws EmptyException;
 }

Нет никакого способа гарантировать, что, когда кто-то реализует интерфейс, popсгенерирует исключение, если стек пуст. Мы могли бы применить это правило, разделив его popна два метода: public finalметод, обеспечивающий выполнение контракта, и protected abstractметод, который выполняет фактическое выталкивание.

public abstract class Stack<T> {
    public abstract boolean isEmpty();

    protected abstract T pop_implementation();

    public final T pop() throws EmptyException {
        if (isEmpty()) {
            throw new EmptyException();
        else {
            return pop_implementation();
        }
    }
 }

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

Я не уверен, позволяет ли подход Java 8 к добавлению методов к интерфейсам добавлять конечные методы или защищенные абстрактные методы, но я знаю, что язык D позволяет это и обеспечивает встроенную поддержку для Design by Contract . В этом методе нет опасности, поскольку он popявляется окончательным, поэтому ни один реализующий класс не может его переопределить.

Что касается реализаций по умолчанию переопределяемых методов, я предполагаю, что любые реализации по умолчанию, добавленные в API Java, полагаются только на контракт интерфейса, к которому они были добавлены, поэтому любой класс, который правильно реализует интерфейс, также будет правильно работать с реализациями по умолчанию.

Кроме того,

Практически нет разницы между интерфейсом и абстрактным классом (кроме множественного наследования). На самом деле вы можете эмулировать обычный класс с интерфейсом.

Это не совсем так, поскольку вы не можете объявить поля в интерфейсе. Любой метод, который вы пишете в интерфейсе, не может полагаться на какие-либо детали реализации.

В качестве примера в пользу статических методов в интерфейсах рассмотрим вспомогательные классы, такие как Collections в Java API. Этот класс существует только потому, что эти статические методы не могут быть объявлены в их соответствующих интерфейсах. Collections.unmodifiableListс таким же успехом мог быть объявлен в Listинтерфейсе, и его было бы легче найти.

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

Эта идея, кажется, связана с тем, как вы можете использовать методы расширения в C # для добавления реализованной функциональности к интерфейсам.

Две основные цели, которые я вижу в defaultметодах (некоторые варианты использования служат обеим целям):

1. Синтаксис сахар. Служебный класс мог бы служить этой цели, но методы экземпляра лучше.
2. Расширение существующего интерфейса. Реализация является общей, но иногда неэффективной.

Если бы речь шла только о второй цели, вы бы не увидели это в совершенно новом интерфейсе Predicate. Все @FunctionalInterfaceаннотированные интерфейсы должны иметь только один абстрактный метод, чтобы лямбда-код мог его реализовать. Добавлены defaultметоды , такие как and, or, negateтолько полезность, и вы не должны переопределить их. Однако иногда статические методы будут лучше .

Что касается расширения существующих интерфейсов - даже там, некоторые новые методы - просто синтаксический сахар. Методы , Collectionкак stream, forEach, removeIf- в основном, это просто утилита вам не нужно переопределить. И тогда есть методы, как spliterator. Реализация по умолчанию является неоптимальной, но, по крайней мере, код компилируется. Прибегайте к этому, только если ваш интерфейс уже опубликован и широко используется.

Что касается staticметодов, я полагаю, что другие достаточно хорошо это понимают: он позволяет интерфейсу быть своим собственным служебным классом. Может быть, мы могли бы избавиться Collectionsв будущем Java? Set.empty()будет качаться