Однією з найбільш корисних особливостей Java 8 є нові defaultметоди інтерфейсів. По суті є дві причини (можуть бути й інші), чому вони були введені:
- Надання фактичних реалізацій за замовчуванням. Приклад:
Iterator.remove() - Дозвіл еволюції API JDK Приклад:
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було б користь у запобіганні впровадженню класів над переосмисленням типової реалізації методу інтерфейсу.