1. Что такое метод по умолчанию и почему должен быть метод по умолчанию?
Проще говоря, интерфейс может иметь методы реализации, и нет необходимости в классе реализации для реализации его методов. Просто добавьте ключевое слово по умолчанию перед именем метода.
Зачем нам нужна эта функция? Прежде всего, предыдущий интерфейс — это палка о двух концах. Преимущество состоит в том, что он ориентирован на абстракцию, а не на конкретное программирование. Недостаток — когда интерфейс необходимо изменить, необходимо изменить все классы, реализующие интерфейс. Текущая платформа сбора данных до версии Java 8 не имеет метода foreach. Обычно возможным решением является добавление новых методов и реализаций к соответствующим интерфейсам в JDK. Однако в выпущенной версии нет возможности добавлять в интерфейс новые методы, не затрагивая существующую реализацию. Итак, введен метод по умолчанию. Их цель — решить проблему несовместимости модификаций интерфейса и существующих реализаций.
Простой пример: интерфейс A, класс Clazz реализует интерфейс A.
Скопируйте код кода следующим образом:
общедоступный интерфейс A {
по умолчанию void foo(){
System.out.println("Вызов A.foo()");
}
}
публичный класс Clazz реализует A {
public static void main(String[] args){
Clazz clazz = новый Clazz();
clazz.foo();//Вызов A.foo()
}
}
Код компилируется, хотя класс Clazz не реализует метод foo(). Реализация метода foo() по умолчанию представлена в интерфейсе A.
2. Сравнение абстрактных классов и интерфейсов в Java 8.
После появления этой функциональной возможности многие студенты отреагировали на то, что у интерфейсов Java 8 есть методы реализации. В чем разница между ними и абстрактными классами? На самом деле, они еще есть, для сравнения см. таблицу ниже. .
| Сходства | Различия |
1. Все они абстрактные типы; 2. Способы реализации могут быть у всех (раньше интерфейсы не работали); 3. Вы можете реализовать все методы без реализации классов или наследников (раньше это было невозможно, теперь методы по умолчанию в интерфейсе не должны быть реализованы разработчиком) | 1. Абстрактные классы не могут иметь множественное наследование, интерфейсы могут (будь то наследование множественного типа или наследование множественного поведения); 2. Абстрактные классы и интерфейсы отражают различные концепции дизайна. Фактически, абстрактные классы представляют отношение «есть», а интерфейсы представляют отношение «как-а»; 3. Переменные, определенные в интерфейсе по умолчанию, имеют общедоступный статический конечный тип, и их начальное значение должно быть задано, поэтому их нельзя переопределить в классе реализации, а также нельзя изменить их значения в абстрактном классе по умолчанию; к дружественному типу, а их значения можно указать в подклассе. Его можно переопределить в классе или переназначить. |
3. Описание конфликта множественного наследования
Поскольку один и тот же метод может быть введен из разных интерфейсов, естественно будут возникать конфликты. Правила определения конфликтов методами по умолчанию следующие:
1. Метод, объявленный в классе, имеет приоритет над любым методом по умолчанию (классы всегда выигрывают).
2. В противном случае сначала будет выбрана наиболее конкретная реализация. Например, в примере ниже B переписывает метод hello A.
Вывод: Привет, мир от B.
Если вы хотите вызвать функцию по умолчанию для A, используйте новый синтаксис X.super.m(...). Затем измените класс C, реализуйте интерфейс A и перепишите метод hello, как показано ниже:
Скопируйте код кода следующим образом:
публичный класс C реализует A{
@Override
общественный недействительный привет () {
А.супер.привет();
}
public static void main(String[] args){
новый C().hello();
}
}
Вывод: Привет, мир от А.
4. Резюме
Метод по умолчанию предоставляет нам удобство изменения интерфейса без разрушения структуры исходного класса реализации. В настоящее время среда сбора данных Java 8 широко использует методы по умолчанию для ее улучшения. Когда мы наконец начинаем использовать лямбда-выражение. Java 8 предусмотрен для У нас есть плавный переход. Возможно, в будущем мы увидим больше применений методов по умолчанию при проектировании API.