Одной из наиболее полезных функций Java 8 являются новые defaultметоды интерфейсов. По сути, есть две причины (могут быть и другие), почему они были введены:
- Предоставление фактических реализаций по умолчанию. Пример:
Iterator.remove() - С учетом эволюции JDK API. Пример:
Iterable.forEach()
С точки зрения разработчика API, мне бы хотелось иметь возможность использовать другие модификаторы в методах интерфейса, например final. Это было бы полезно при добавлении вспомогательных методов, предотвращающих «случайные» переопределения при реализации классов:
interface Sender {
// Convenience method to send an empty message
default final void send() {
send(null);
}
// Implementations should only implement this method
void send(String message);
}Вышесказанное уже является обычной практикой, если бы Senderбыл класс:
abstract class Sender {
// Convenience method to send an empty message
final void send() {
send(null);
}
// Implementations should only implement this method
abstract void send(String message);
}Теперь, defaultи finalони явно противоречат ключевым словам, но само ключевое слово по умолчанию не было бы строго обязательным , поэтому я предполагаю, что это противоречие является преднамеренным, чтобы отразить тонкие различия между «методами класса с телом» (только методы) и «интерфейсом». "методы с телом" (методы по умолчанию), т.е. различия, которые я еще не понял.
В какой-то момент поддержка модификаторов, таких как staticи finalв интерфейсных методах, еще не была полностью изучена, ссылаясь на Брайана Гетца :
Другая часть заключается в том, как далеко мы пойдем, чтобы поддерживать инструменты построения классов в интерфейсах, такие как конечные методы, частные методы, защищенные методы, статические методы и т. Д. Ответ: мы еще не знаем
С тех пор, в конце 2011 года, очевидно, staticбыла добавлена поддержка методов в интерфейсах. Понятно, что это добавило много ценности самим библиотекам JDK, например, с помощью Comparator.comparing().
Вопрос:
По какой причине final(а также static final) никогда не доходило до интерфейсов Java 8?
finalпредотвращает переопределение метода, и, видя, как вы ДОЛЖНЫ переопределять методы, унаследованные от интерфейсов, я не понимаю, почему имеет смысл сделать его окончательным. Если только это не означало, что метод является окончательным ПОСЛЕ переопределения его один раз .. В таком случае, может быть, есть трудности? Если я не понимаю этого права, пожалуйста, дайте мне знать. Кажется интересным
finalможно было бы использовать предотвращение реализации классами переопределения реализации метода интерфейса по умолчанию.