Почему все поля в интерфейсе неявно статичны и окончательны?

Я просто пытаюсь понять, почему все поля, определенные в интерфейсе, неявно static и final . Идея сохранения полей static для меня, поскольку у вас нет объектов интерфейса, но почему они являются final (неявно)?

Кто-нибудь знает, почему дизайнеры Java пошли с созданием полей в static и final интерфейсе?

    7 Solutions collect form web for “Почему все поля в интерфейсе неявно статичны и окончательны?”

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

    BTW: константа в Java определяется статическим конечным полем (и по соглашению имя использует UPPER_CASE_AND_UNDERSCORES).

    ПРИЧИНА ДЛЯ БЫТИЯ

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

    ПРИЧИНА ДЛЯ СТАТЬИ

    Если они статичны, то они принадлежат интерфейсу, а не объекту, а также типу времени выполнения объекта.

    Здесь есть несколько моментов:

    Просто потому, что поля в интерфейсе неявно статичны, это не значит, что они должны быть константами времени компиляции или даже неизменными. Вы можете определить, например

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

    (Остерегайтесь того, что выполнение этого внутри определения annotations может смутить javac , связанное с тем, что вышеописанное фактически компилируется в статический инициализатор.)

    Кроме того, причина этого ограничения более стильная, чем техническая, и многие люди хотели бы, чтобы это было расслаблено .

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

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

    Только моя мысль.

    Я считаю необходимым, чтобы поля были окончательными как чрезмерно ограничительные и ошибки разработчиков языка Java. Бывают случаи, например, обработка дерева, когда вам нужно установить константы в реализации, которые необходимы для выполнения операций над объектом типа интерфейса. Выбор пути кода в classе реализации – это kludge. Обходной путь, который я использую, – это определить функцию интерфейса и реализовать его, возвращая литерал:

     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"; ... } 

    Спецификация, контракты … В машинной инструкции для доступа к полю используется адрес объекта плюс смещение поля. Поскольку classы могут реализовывать множество интерфейсов, нет никакого способа сделать нефинальное поле интерфейса одинаковым смещением во всех classах, расширяющих этот интерфейс. Поэтому должен быть реализован другой механизм доступа к полям: два обращения к памяти (получить смещение поля, получить значение поля) вместо одного плюс поддерживающий вид таблицы виртуальных полей (аналог таблицы виртуальных методов). Угадайте, что они просто не хотели усложнять jvm для функциональности, которую можно легко смоделировать с помощью существующего материала (методов).

    В scala мы можем иметь поля в интерфейсах, хотя внутри они реализованы, как я объяснил выше (как методы).

    static :

    Любое (переменная или метод), static в Java, может быть вызвано как Classname.variablename или Classname.methodname или напрямую. Не обязательно вызывать его только с помощью имени объекта.

    В интерфейсе объекты не могут быть объявлены, а static позволяет вызывать переменные только через имя classа без необходимости имени объекта.

    final :

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

    Interesting Posts

    Как вернуть несколько значений из функции в C?

    Каковы истинные преимущества ExpandoObject?

    Не удается удалить бесконечно повторяющуюся папку в папке в папке и т. Д.

    Длинные команды, разделенные на несколько строк в пакетном (.bat) файле Windows Vista

    Преобразование float в std :: string в C ++

    Как начать nginx на порту 80 при входе в систему OS X?

    Почему размер массива не такой же, как и у основного?

    Ответы на конкретный твит, API Twitter

    Как вставить функцию = now () в ячейку автоматически, когда я пишу в другой, и нажмите enter

    В какой папке находятся журналы установки?

    Подробная информация о Wi-Fi

    Не найдено ни одного подходящего клиента для имени пакета (Google Analytics) – несколько продуктовFlavors & buildTypes

    Получить значение кнопки с помощью jQuery

    Процесс приостановки в C #

    Разделение csv-файла с кавычками как разделитель текста с помощью String.split ()

    Давайте будем гением компьютера.