Почему в интерфейсах нет статических методов, но есть статические поля и внутренние классы? [pre-Java8]

Было сделано официальное предложение, чтобы разрешить статические методы в интерфейсах в Java 7. . Это предложение сделано в рамках Project Coin.

Лично я считаю, что это отличная идея. Технических сложностей в реализации нет, и это очень логично и разумно. В Project Coin есть несколько предложений, которые, я надеюсь, никогда не станут частью языка Java, но это то, что могло бы очистить многие API. Например, Collections класс имеет статические методы для управления любой List реализацией; они могут быть включены в List интерфейс.

Обновление: в подкасте Java Posse № 234, Джо Д. Арси кратко упомянул предложение, сказав, что оно «сложное» и, вероятно, не войдет в проект Coin.

Обновление. Хотя они не вошли в Project Coin для Java 7, Java 8 поддерживает статические функции в интерфейсах.

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

Статические поля присутствуют (а) потому, что они присутствовали в JDK 1.0, и в JDK 1.0 было принято много хитрых решений, и (б) статические конечные поля в интерфейсах - это самое близкое к константам то, что в то время было в java.

Статические внутренние классы в интерфейсах были разрешены, потому что это чистый синтаксический сахар - внутренний класс на самом деле не имеет ничего общего с родительским классом.

Так что статические методы не разрешены просто потому, что для этого нет веских причин; последовательность не достаточно убедительна, чтобы изменить статус-кво.

Конечно, это может быть разрешено в будущих версиях JLS, ничего не нарушая.

Нет смысла объявлять статический метод в интерфейсе. Они не могут быть выполнены обычным вызовом MyInterface.staticMethod (). (РЕДАКТИРОВАТЬ: поскольку это последнее предложение смутило некоторых людей, вызов MyClass.staticMethod () выполняет именно реализацию staticMethod на MyClass, который, если MyClass является интерфейсом, не может существовать!) Если вы вызываете их, указав реализующий класс MyImplementor.staticMethod () тогда вы должны знать фактический класс, поэтому не имеет значения, содержит ли его интерфейс или нет.

Что еще более важно, статические методы никогда не переопределяются, и если вы попытаетесь это сделать:

MyInterface var = new MyImplementingClass();
var.staticMethod();

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

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

Чтобы ответить на некоторые из приведенных ниже комментариев, причина, по которой вы не можете выполнить "result = MyInterface.staticMethod ()", заключается в том, что ему придется выполнить версию метода, определенную в MyInterface. Но в MyInterface не может быть версии, потому что это интерфейс. У него нет кода по определению.

Назначение интерфейсов - определить контракт без предоставления реализации. Следовательно, у вас не может быть статических методов, потому что они должны иметь реализацию уже в интерфейсе, поскольку вы не можете переопределить статические методы. Что касается полей, разрешены только статические final fields, которые, по сути, являются константами (в 1.5+ вы также можете иметь перечисления в интерфейсах). Константы нужны, чтобы помочь определить интерфейс без магических чисел.

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

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

Основная цель интерфейса - предоставить что-то, что невозможно реализовать, поэтому, если они предоставляют

статические методы должны быть разрешены

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

статические поля разрешены

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

Внутренние классы разрешены

Внутренние классы разрешены, потому что после компиляции создается другой файл класса внутреннего класса, например InterfaceName $ InnerClassName.class, поэтому в основном вы предоставляете реализацию в другом объекте все вместе, но не в интерфейсе. Так что реализация во внутренних классах предусмотрена.

Надеюсь, это поможет.

На самом деле, иногда есть причины, по которым кому-то могут быть полезны статические методы. Их можно использовать как фабричные методы для классов, реализующих интерфейс. Например, по этой причине у нас теперь есть интерфейс Collection и класс Collections в openjdk. Так что, как всегда, есть обходные пути - предоставьте другому классу частный конструктор, который будет служить «пространством имен» для статических методов.

До Java 5 обычное использование статических полей было:

interface HtmlConstants {
    static String OPEN = "<";
    static String SLASH_OPEN = "</";
    static String CLOSE = ">";
    static String SLASH_CLOSE = " />";
    static String HTML = "html";
    static String BODY = "body";
    ...
}

public class HtmlBuilder implements HtmlConstants { // implements ?!?
    public String buildHtml() {
       StringBuffer sb = new StringBuffer();
       sb.append(OPEN).append(HTML).append(CLOSE);
       sb.append(OPEN).append(BODY).append(CLOSE);
       ...
       sb.append(SLASH_OPEN).append(BODY).append(CLOSE);
       sb.append(SLASH_OPEN).append(HTML).append(CLOSE);
       return sb.toString();
    }
}

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

Использование такого оборудования в конечном итоге сбивает с толку.

Теперь с Java 5 у нас есть синтаксис import static для достижения того же эффекта:

private final class HtmlConstants {
    ...
    private HtmlConstants() { /* empty */ }
}

import static HtmlConstants.*;
public class HtmlBuilder { // no longer uses implements
    ...
}

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

Я часто задаюсь вопросом, зачем вообще статические методы? У них есть свое применение, но методы уровня пакета / пространства имен, вероятно, охватывают 80 из того, для чего используются статические методы.

На ум приходят две основные причины:

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

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

Статические методы привязаны к классу. В Java интерфейс технически не является классом, это тип, но не класс (следовательно, ключевое слово реализует, а интерфейсы не расширяют Object). Поскольку интерфейсы не являются классами, у них не может быть статических методов, потому что нет реального класса, к которому можно было бы присоединиться.

Вы можете вызвать InterfaceName.class, чтобы получить объект класса, соответствующий интерфейсу, но в классе Class конкретно указано, что он представляет классы и интерфейсы в приложении Java. Однако сам интерфейс не рассматривается как класс, и, следовательно, вы не можете присоединить статический метод.

В интерфейсе могут быть объявлены только статические поля final (подобно методам, которые являются общедоступными, даже если вы не включаете ключевое слово «public», статические поля являются «окончательными» с ключевым словом или без него).

Это всего лишь значения, и они будут скопированы буквально везде, где они используются во время компиляции, поэтому вы никогда не «вызываете» статические поля во время выполнения. У статического метода не будет такой же семантики, поскольку он будет включать вызов интерфейса без реализации, что не позволяет Java.

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

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

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

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

Статический метод интерфейса Java 1.8 виден только для методов интерфейса. Если мы удалим метод methodSta1 () из класса InterfaceExample, мы не сможем использовать его для объекта InterfaceExample. Однако, как и другие статические методы, мы можем использовать статические методы интерфейса, используя имя класса. Например, допустимым заявлением будет: exp1.methodSta1 ();

Итак, посмотрев пример ниже, мы можем сказать: 1) Статический метод интерфейса Java является частью интерфейса, мы не можем использовать его для объектов класса реализации.

2) Статические методы интерфейса Java хороши для предоставления служебных методов, например нулевой проверки, сортировки коллекции, журнала и т. Д.

3) Статический метод интерфейса Java помогает нам в обеспечении безопасности, не позволяя классам реализации (InterfaceExample) переопределять их.

4) Мы не можем определить статический метод интерфейса для методов класса Object, мы получим ошибку компилятора, поскольку «Этот статический метод не может скрыть метод экземпляра от Object». Это потому, что это не разрешено в java, поскольку Object является базовым классом для всех классов, и у нас не может быть одного статического метода уровня класса и другого метода экземпляра с той же сигнатурой.

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

public class InterfaceExample implements exp1 {

    @Override
    public void method() {
        System.out.println("From method()");
    }

    public static void main(String[] args) {
        new InterfaceExample().method2();
        InterfaceExample.methodSta2();      //  <---------------------------    would not compile
        // methodSta1();                        //  <---------------------------    would not compile
        exp1.methodSta1();
    }

    static void methodSta2() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= InterfaceExample :: from methodSta2() ======");
    }
}


interface exp1 {

    void method();
    //protected void method1();         //          <--      error
    //private void method2();           //          <--      error
    //static void methodSta1();         //          <--      error it require body in java 1.8

    static void methodSta1() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= exp1:: from methodSta1() ======");
    }

    static void methodSta2() {          //          <-- it compile successfully but it can't be overridden in child classes
        System.out.println("========= exp1:: from methodSta2() ======");
    }

    default void method2() { System.out.println("---  exp1:: from method2() ---");}
    //synchronized default void method3() { System.out.println("---");}             // <-- Illegal modifier for the interface method method3; only public, abstract, default, static 
                                                                                // and strictfp are permitted
    //final default void method3() { System.out.println("---");} //             <--      error
}