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


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

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

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


Answers



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

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




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

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

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

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



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

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

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

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

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

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




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

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




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




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

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




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

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

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




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

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

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




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

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




С введением 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() {}

}



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