Чому всі поля в інтерфейсі неявно статичні та кінцеві?

Я просто намагаюся зрозуміти, чому всі поля, визначені в інтерфейсі, неявно staticі final. Ідея зберігати поля staticмає для мене сенс, оскільки ви не можете мати об'єкти інтерфейсу, але чому вони є final(неявно)?

Хтось знає, чому дизайнери Java пішли із створенням поля в інтерфейс staticі final?

Інтерфейс не може мати поведінку або стан, оскільки він призначений лише для визначення договору про взаємодію, без деталей щодо імплементації. "Ніяка поведінка" не застосовується, не дозволяючи тілам методів / конструкторів або статичним / екземпляром ініціалізації блоків. "Ніякого стану" не застосовується, лише дозволяючи статичні кінцеві поля. Отже, клас може мати стан (статичний стан), але стан екземпляра не виводиться інтерфейсом.

BTW: Константа в Java визначається статичним кінцевим полем (а за умовою назва використовує UPPER_CASE_AND_UNDERSCORES).

Причина існування final

Будь-які реалізації можуть змінювати значення полів, якщо вони не визначені як кінцеві. Тоді вони стануть частиною реалізації. Інтерфейс - це чиста специфікація без будь-якої реалізації.

Причина існування static

Якщо вони статичні, то вони належать до інтерфейсу, а не до об'єкта, а також до типу виконання об'єкта.

Тут заглянуто кілька точок:

Тільки тому, що поля в інтерфейсі неявно статичні остаточні, не означає, що вони повинні бути константами часу компіляції або навіть незмінними. Ви можете визначити, наприклад

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Будьте уважні, якщо це робити всередині визначення приміток, можна заплутати javac , пов'язане з тим, що вищезазначене насправді компілюється в статичний ініціалізатор.)

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

Поля повинні бути статичними, оскільки вони не можуть бути абстрактними (як методи можуть). Оскільки вони не можуть бути абстрактними, реалізатори не зможуть логічно забезпечити різну реалізацію полів.

Я думаю, що поля повинні бути остаточними, тому що доступ до полів може здійснюватися багатьма різними реалізаторами, що дозволяє змінювати їх, можливо, проблематично (як синхронізація). Також щоб уникнути його повторної реалізації (прихованого).

Просто моя думка.

Я вважаю вимогу, щоб поля були остаточними як надмірно обмежувальні та помилки з боку дизайнерів мови Java. Бувають випадки, наприклад, обробка дерева, коли вам потрібно встановити константи в реалізації, необхідні для виконання операцій над об'єктом типу інтерфейсу. Вибір шляху коду на клас реалізації - це хитрощі. Завдання, яке я використовую, - це визначити функцію інтерфейсу та реалізувати її, повернувши буквальне:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Однак використовувати цей синтаксис було б простіше, зрозуміліше і менш схильне до аберантної реалізації:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Специфікація, контракти ... Машинна інструкція для доступу до поля використовує адресу об'єкта плюс зміщення поля. Оскільки класи можуть реалізовувати безліч інтерфейсів, немає способу зробити поле, яке не завершує інтерфейс, для однакового зміщення у всіх класах, що розширюють цей інтерфейс. Тому необхідно запровадити різний механізм доступу до поля: два доступу до пам'яті (зміщення поля, отримання значення поля) замість одного плюс підтримка виду таблиці віртуальної поля (аналог таблиці віртуальних методів). Здається, вони просто не хотіли ускладнювати jvm для функціональності, який можна легко імітувати за допомогою існуючих матеріалів (методів).

У масштабі ми можемо мати поля в інтерфейсах, хоча внутрішньо вони реалізовані, як я пояснив вище (як методи).

static:

Будь-яке (змінна чи метод), яке є staticна Java, може викликатися як Classname.variablenameабоClassname.methodname або безпосередньо. Не обов’язково викликати його лише за допомогою імені об'єкта.

В інтерфейсі об'єкти не можуть бути оголошені, і staticце дозволяє викликати змінні просто через ім'я класу без необхідності імені об'єкта.

final:

Це допомагає підтримувати постійну величину для змінної, оскільки її не можна перекрити в своїх підкласах.