Почему добавление методов по умолчанию для интерфейсов в Java 8 - хороший выбор дизайна и какие альтернативы

Я просто изучаю Java, поэтому мне трудно получить доступ к возможным альтернативам и влиянию такого дизайнерского решения.

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

  • Почему появилась эта языковая функция?
  • Какие ключевые новые функции он поддерживает? (например, разделители)
  • Какие еще альтернативы были для поддержки этих языковых функций? Например, почему бы не создать новый интерфейс SplitIterable, который расширяет Iterable?
  • Каким будет влияние реализации этих альтернатив (распространение интерфейсов?)
  • Должен ли я предоставить реализацию по умолчанию для метода в первом редакторе интерфейса, когда его можно реализовать как состав других методов?

ОТВЕТЫ

Ответ 1

Почему появилась эта языковая функция?

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

Какие ключевые новые функции он поддерживает? (например, Splititerators)

java.util.Collection<T>.stream()

Какие еще альтернативы были для поддержки этих языковых функций? Например, почему бы не создать новый интерфейс SplitIterable, который расширяет Iterable?

Вы можете выбрать совершенно новые интерфейсы и продолжить сопутствующий статический вспомогательный класс (например, Collection<T> interface и его Collections вспомогательный класс). Это не было бы ужасно - на самом деле можно утверждать, что методы по умолчанию - это просто синтаксический сахар поверх статических методов *. Однако методы по умолчанию обычно обеспечивают лучшую читаемость.

Каким будет влияние реализации этих альтернатив (распространение интерфейсов?)

У вас будет менее согласованная библиотека и менее читаемый язык, но это не будет конец света. Более серьезная проблема, о которой говорил Joachim Sauer, заключается в том, что реализации интерфейса не будут иметь возможности переопределить реализацию из статического вспомогательного класса. Это уберет гибкость.

Должен ли я предоставить реализацию по умолчанию для метода в первом редакторе интерфейса, когда его можно реализовать как состав других методов?

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

* Это будет упрощением, поскольку методы по умолчанию остаются виртуальными. Спасибо Брайан Гетц за комментарий.