Публичное статическое окончательное объявление переменных экземпляра в интерфейсах JAVA

Ответ 1

Использование единого синтаксиса в обоих классах и интерфейсах упрощает рефакторинг.

Вы можете захотеть превратить ваш interface в class где-то в будущем или переместить эти поля в класс, и вы получите семантическую разницу, если вы упустите некоторые поля, определенные без public static final (конечно, у нас есть инструменты для рефакторинга, но тем не менее).

Я думаю, что это то же самое, что поддержка аннотации @Overriden для реализаций методов, объявленных в интерфейсах, которые были введены в Java 6 - она ​​избыточна в своей текущей форме, но может стать полезной в случае рефакторинга.

Ответ 2

Я так не думаю. Все интерфейсные переменные неявно являются публичными статическими, поэтому нет смысла их отмечать одинаково.

Ответ 3

Из книги "Эффективная ява" Джошуа Блоха

Пункт 19: Используйте интерфейсы только для определения типов

Когда класс реализует интерфейс, интерфейс служит типом, который может для ссылки на экземпляры класса. Что класс реализует интерфейс поэтому следует сказать что-то о том, что клиент может делать с примерами класс. Неправильно определять интерфейс для каких-либо других целей.

Одним из видов интерфейса, который не прошел этот тест, является так называемый постоянный интерфейс. Такой интерфейс не содержит методов; он состоит исключительно из статических конечных полей, каждый экспорт константы. Классы, использующие эти константы, реализуют интерфейс для избегайте необходимости определять постоянные имена с именем класса. Вот пример:

// Constant interface antipattern - do not use!
public interface PhysicalConstants {
    // Avogadro number (1/mol)
    static final double AVOGADROS_NUMBER = 6.02214199e23;
    // Boltzmann constant (J/K)
    static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    // Mass of the electron (kg)
    static final double ELECTRON_MASS = 9.10938188e-31;
}

Постоянный шаблон интерфейса плохо использует интерфейсы. Что класс использует некоторые константы внутри - это детализация реализации. Внедрение константы интерфейс заставляет эту деталь реализации протекать в API-интерфейсах, экспортированных классами. Это не имеет никакого значения для пользователей класса, который класс реализует константу интерфейс. На самом деле это может даже запутать их. Хуже того, он представляет собой обязательство: если в будущей версии класс модифицируется так, что ему больше не нужно использовать константы, он все равно должен реализовать интерфейс для обеспечения совместимости двоичных файлов. Если нефинальный класс реализует постоянный интерфейс, все его подклассы будут иметь свои пространства имен, загрязненные константами в интерфейсе.

В библиотеках платформы Java существует несколько постоянных интерфейсов, таких как java.io.ObjectStreamConstants. Эти интерфейсы следует рассматривать как аномалии и не должны эмулироваться.

Если вы хотите экспортировать константы, существует несколько разумных вариантов. Если константы сильно привязаны к существующему классу или интерфейсу, вы должны добавить их в класс или интерфейс. Например, все классы с числовыми примитивами в штучной упаковке, таких как Integer и Double, экспортируйте константы MIN_VALUE и MAX_VALUE. Если константы лучше всего рассматривать как члены перечисленного типа, вы должны экспортировать их с типом перечисления (пункт 30). В противном случае вы должны экспортировать константы с неинтегрируемым классом полезности (пункт 4). Вот версия служебного класса Пример PhysicalConstants выше:

// Constant utility class
package com.effectivejava.science;

public class PhysicalConstants {
    private PhysicalConstants() {
    } // Prevents instantiation

    public static final double AVOGADROS_NUMBER = 6.02214199e23;
    public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
    public static final double ELECTRON_MASS = 9.10938188e-31;
}

Обычно класс утилиты требует, чтобы клиенты квалифицировали постоянные имена с классом имя, например, PhysicalConstants.AVOGADROS_NUMBER. Если вы делаете тяжелые использование констант, экспортируемых служебным классом, вы можете избежать необходимости в квалификации константы с именем класса, используя статический механизм импорта, введенный в релиз 1.5:

// Use of static import to avoid qualifying constants
import static com.effectivejava.science.PhysicalConstants.*;
public class Test {
    double atoms(double mols) {
        return AVOGADROS_NUMBER * mols;
    }
...
// Many more uses of PhysicalConstants justify static import
}

Таким образом, интерфейсы должны использоваться только для определения типов. Они не должны для экспорта констант.

Ответ 4

IMO, интерфейс - это контракт. Как только переменные объявлены или определены, они не будут меняться. Вот почему мы обычно делаем их public static final.

Чтение - еще один фактор, который делает объявление излишним.

Ответ 5

По общему признанию, он избыточен. Обычно люди просто не знают, что они неявно public static final и объявляют его в любом случае. То же самое с объявлением:

public abstract interface Test { // Interfaces are always abstract
    public void testMethod(); // Interface methods are always public
    abstract void anotherTestMethod(); // Also redundant
}

Обычно это сводится к тому, что люди не знают, что им не нужно объявлять это так или иначе. Я однажды поговорил с кем-то (кто был опытным программистом), который думал, что дело default в switch требуется или оно не будет компилироваться.

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

Ответ 6

Когда вы работаете в команде программистов, вы найдете младших программистов, которые не знают, что по умолчанию переменные public static final в интерфейсе и видят объявленные переменные способ даст им дополнительную информацию об интерфейсе и использовании его переменных.

Ответ 7

Вы правы: это избыточно. Я не люблю добавлять избыточный синтаксис в любое время. Однако практика имеет своих сторонников. Некоторым также нравится добавлять круглые скобки вокруг возвращаемых выражений, на ошибочных основаниях, что это похоже на выражение "если"; дополнительные круглые скобки для "уточнения" арифметических выражений, которые понимал бы третий класс; и т.д. Все это часть богатого гобелена жизни.