Должны ли методы в интерфейсе Java быть объявлены с модификатором открытого доступа или без него?

Должны ли методы в интерфейсе Java быть объявлены с publicмодификатором доступа или без него ?

Технически это не имеет значения, конечно. Метод класса, который реализует interfaceвсегда public. Но что является лучшим соглашением?

Сама Java не соответствует этому. Смотрите, например, Collectionпротив Comparableили Futureпротив ScriptEngine.

JLS делает это ясно:

Разрешается, но не рекомендуется в качестве стиля, избыточно указывать модификатор publicи / или abstractдля метода, объявленного в интерфейсе.

Модификатор public должен быть опущен в интерфейсах Java (по моему мнению).

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

Большинство руководств по стилю рекомендуют не указывать это, но, конечно, самое важное - это согласованность по всей базе кода, особенно для каждого интерфейса. Следующий пример может легко запутать кого-то, кто не владеет Java на 100%:

public interface Foo{
  public void MakeFoo();
  void PerformBar();
}

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

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

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

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

В-четвертых, Интерфейс может включать в себя только константы в качестве своих элементов данных, что означает, что они должны быть конечными, и, конечно, конечные константы объявляются как статические, чтобы сохранить только один их экземпляр. Поэтому static final также является обязательным для констант интерфейса.

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

С введением private, static, defaultмодификаторы методов интерфейса в Java 8/9, вещи становятся более сложными , и я склонен думать , что полные декларации более читаемые (требуется Java 9 для компиляции):

public interface MyInterface {

    //minimal
    int CONST00 = 0;
    void method00();
    static void method01() {}
    default void method02() {}
    private static void method03() {}
    private void method04() {}

    //full
    public static final int CONST10 = 0;
    public abstract void method10();
    public static void method11() {}
    public default void method12() {}
    private static void method13() {}
    private void method14() {}

}

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

Худшее, что я видел, это интерфейс с объявленными методами abstract...

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

Так что я не совсем уверен, что лучше, но мне очень не нравится использовать public abstractметоды интерфейса. Eclipse делает это иногда при рефакторинге с помощью «Extract Interface».

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

Я предпочитаю пропустить это, я где-то читал, что интерфейсы по умолчанию, publicи abstract.

К моему удивлению, книга - Head First Design Patterns , использует publicс объявлением интерфейса и методами интерфейса ..., что заставило меня переосмыслить еще раз, и я попал на этот пост.

В любом случае, я думаю, что избыточную информацию следует игнорировать.

Я не согласен с популярным ответом: публичность подразумевает, что есть и другие варианты, поэтому их не должно быть. Дело в том, что теперь с Java 9 и за его пределами есть другие варианты.

Я думаю, что вместо этого Java должен обеспечивать / требовать указания 'public'. Зачем? Поскольку отсутствие модификатора означает «пакетный» доступ везде, а наличие этого в качестве особого случая приводит к путанице. Если бы вы просто сделали это ошибкой компиляции с четким сообщением (например, «Доступ к пакету не разрешен в интерфейсе».), Мы избавились бы от очевидной двусмысленности, которую дает возможность опустить «public».

Обратите внимание на текущую формулировку по адресу: https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.4.

«Метод в теле интерфейса может быть объявлен общедоступным или частным (§6.6). Если модификатор доступа не указан, метод является неявно общедоступным. Разрешается, но не рекомендуется в качестве стиля, избыточно указывать общедоступный модификатор для объявления метода в интерфейсе. "

Смотрите, что «личное» разрешено сейчас. Я думаю, что последнее предложение должно быть удалено из JLS. К сожалению, «неявно публичное» поведение было когда-либо разрешено, поскольку теперь оно, скорее всего, останется для обратной совместимости и приведет к путанице, что отсутствие модификатора доступа означает «открытый» в интерфейсах и «пакет» в других местах.

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

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

Добавление этих модификаторов в ваш код является излишним и бесполезным и может привести только к выводу, что вам не хватает знаний и / или понимания основ Java.

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

Интересно отметить, что разработчики языка C # решили применить это. Объявление метода интерфейса как общедоступного в C # на самом деле является ошибкой компиляции. Согласованность, вероятно, не важна для разных языков, поэтому, я думаю, это не имеет прямого отношения к Java.

Люди узнают ваш интерфейс по завершению кода в своей IDE или в Javadoc, а не по чтению исходного кода. Так что нет смысла помещать «публичный» в источник - никто не читает источник.