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

Теперь мы знаем, что Java 8 представила стандартные и статические методы в интерфейсах.
Интерфейсы были первоначально введены на Java, чтобы избежать the diamond problem, которые произошли на C++, в многократном наследовании.Предпочтения абстрактных классов по интерфейсам в Java 8

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

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

Так что теперь у меня есть три вопроса, на мой взгляд:

Почему необходимо иметь стандартные методы?
Не могли бы мы иметь множественное наследование через классы, вместо методов по умолчанию в интерфейсах?
И в чем же заключалась необходимость избежать проблемы с алмазом в предыдущих версиях, если бы им пришлось вводить ее на Java 8?

Любое хорошее объяснение или любая ссылка для объяснения?

PS Я не нашёл никакой ссылки в Интернете, содержащей хорошую статью об этом.
Все, что они сказали, что абстрактный класс дает вам больше конкретности.
Как и в случае, абстрактные классы могут иметь конструкторы, но интерфейсы не могут.

Итак, еще раз хочу знать, если абстрактные классы более конкретны и могут иметь конструкторы,
и в любом случае Java представила проблему с алмазами, почему у нас должны быть интерфейсы сейчас? Разве абстрактные классы не будут достаточно хороши, как самостоятельные для множественного наследования?

источник

2014-06-23 Aditya Singh

возможно дубликат [Каковы различия между абстрактными классами и интерфейсами в Java 8?] (Http://stackoverflow.com/questions/22591499/what-are-the- difference-between-abstract-classes-and-interfaces-in-java-8) – assylias

Этот дубликат не отвечает на мой вопрос. Поэтому я не буду рассматривать его как дубликат. Посмотрите на третий комментарий ответа JB Nizet для дальнейшего оформления того, что мой вопрос. –

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

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

Итак, вот ответы на вопросы:

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

источник

2014-06-23 12:01:58

Спасибо, Но действительно ли у нас есть возможность выбрать любую из предоставленных реализаций? Например, если 'интерфейс A' и' интерфейс B' оба имеют 'public default void hello()' метод, а 'Class Inheritance реализует A, B', тогда у' класса Inheritance' есть возможность выбрать 'public default void hello() 'из' интерфейса A' и игнорировать его из 'интерфейса B', не переопределяя его? –

Да, есть. 'public void hello() {A.super.hello(); } ' –

И то же самое можно было бы сделать и с классами. Если бы 'A' и' B' были классами вместо интерфейсов, то и то же самое можно было бы сделать с ними. Итак, остается вопрос, зачем нам нужны интерфейсы, если то же самое можно было бы сделать с помощью классов? Вместо 'A.super.hello()' мы могли бы иметь что-то вроде 'A.superClass.hello()', если 'A' и' B' были классами и 'Inheritance' расширили их (множественное наследование с классами). 'superClass' не является ключевым словом. Я говорю это только ради объяснения моего мнения. –

Что касается пункта 1:

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

посмотреть это видео подробно Lambda Peak Under the hood

источник

2014-06-23 12:05:59

Я видел это видео раньше. Но то же самое можно было бы сделать с помощью классов. –

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

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

Подробнее здесь https://docs.oracle.com/javase/tutorial/java/IandI/nogrow.html

источник

2015-06-25 12:03:31 octoback

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

ответ

Смежные вопросы