Об этом уже спросили и ответили: здесь

Чтобы продублировать мой ответ:

Нет смысла объявлять статический метод в интерфейсе. Они не могут быть выполнены обычным вызовом MyInterface.staticMethod (). Если вы вызываете их, указав реализующий класс MyImplementor.staticMethod (), тогда вы должны знать фактический класс, поэтому не имеет значения, содержит ли интерфейс его или нет.

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

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

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

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

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

Обычно это делается с использованием фабричного паттерна.

public interface IXMLizableFactory<T extends IXMLizable> {
  public T newInstanceFromXML(Element e);
}

public interface IXMLizable {
  public Element toXMLElement();
}

С появлением Java 8 появилась возможность писать в интерфейсе методы по умолчанию и статические. docs.oracle/staticMethod

Например:

public interface Arithmetic {

    public int add(int a, int b);

    public static int multiply(int a, int b) {
        return a * b;
    }
}

public class ArithmaticImplementation implements Arithmetic {

    @Override
    public int add(int a, int b) {
        return a + b;
    }

    public static void main(String[] args) {
        int result = Arithmetic.multiply(2, 3);
        System.out.println(result);
    }
}

Результат: 6

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

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

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

На самом деле это можно сделать в Java 8.

Согласно Java doc:

Статический метод - это метод, связанный с классом, в котором он определен, а не с каким-либо объектом. Каждый экземпляр класса использует свои статические методы

В Java 8 интерфейс может иметь методы по умолчанию и статические методы. Это упрощает организацию вспомогательных методов в наших библиотеках. Мы можем хранить статические методы, специфичные для интерфейса, в том же интерфейсе, а не в отдельном классе.

Пример метода по умолчанию:

list.sort(ordering);

вместо того

Collections.sort(list, ordering);

Пример статического метода (из самого документа):

public interface TimeClient {
    // ...
    static public ZoneId getZoneId (String zoneString) {
        try {
            return ZoneId.of(zoneString);
        } catch (DateTimeException e) {
            System.err.println("Invalid time zone: " + zoneString +
                "; using default time zone instead.");
            return ZoneId.systemDefault();
        }
    }

    default public ZonedDateTime getZonedDateTime(String zoneString) {
        return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));
    }    
}

Интерфейсы связаны с полиморфизмом, который по своей сути привязан к экземплярам объектов, а не к классам. Поэтому статика не имеет смысла в контексте интерфейса.

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

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

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

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

Но вы можете помещать классы, содержащие статические методы, внутрь интерфейсов. Вы можете попробовать это!

public interface Test {
    static class Inner {
        public static Object get() {
            return 0;
        }
    }
}

• «Есть ли особая причина, по которой статические методы нельзя переопределить?».

Позвольте мне переформулировать этот вопрос для вас, заполнив определения.

• «Есть ли особая причина, по которой методы, разрешенные во время компиляции, не могут быть разрешены во время выполнения».

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

Комментарии EDIT: As of Java 8, static methods are now allowed in interfaces.

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

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

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

cmd = createCmd(Person.getCreateCmdId());
Person p = cmd.execute();

и для загрузки человека по идентификатору вы бы сделали

cmd = createCmd(Person.getGetCmdId());
cmd.set(ID, id);
Person p = cmd.execute();

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

EJB-компоненты решают эту проблему, имея домашний интерфейс; каждый объект знает, как найти свой Home, а Home содержит «статические» методы. Таким образом, «статические» методы могут быть переопределены по мере необходимости, и вы не загромождаете обычный (он называется «Remote») интерфейс методами, которые не применяются к экземпляру вашего bean-компонента. Просто укажите в обычном интерфейсе метод "getHome ()". Верните экземпляр объекта Home (который, я полагаю, может быть синглтоном), и вызывающий может выполнять операции, которые влияют на все объекты Person.

Why can't I define a static method in a Java interface?

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

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

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

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

Таким образом, наиболее близким приближением к статическому методу в интерфейсе был бы нестатический метод, который игнорирует "this", т.е. не обращается к каким-либо нестатическим членам экземпляра. На низкоуровневой абстракции каждый нестатический метод (после поиска в любой vtable) на самом деле является просто функцией с областью действия класса, которая принимает this как неявный формальный параметр. См. одноэлементный объект Scala и взаимодействие с Java в качестве доказательства этой концепции. Таким образом, каждый статический метод - это функция с областью видимости класса, которая не принимает параметр this. Таким образом, обычно статический метод можно вызывать статически, но, как было сказано ранее, интерфейс не имеет реализации (является абстрактным).

Таким образом, чтобы получить наиболее близкое приближение к статическому методу в интерфейсе, нужно использовать нестатический метод, а затем не обращаться ни к одному из нестатических членов экземпляра. Другим способом не было бы возможного повышения производительности, потому что нет способа статически связать (во время компиляции) ISomething.member(). Единственное преимущество статического метода в интерфейсе, которое я вижу, заключается в том, что он не вводит (т.е. игнорирует) неявное "this" и, таким образом, запрещает доступ к любому из нестатических членов экземпляра. Это будет неявно объявить, что функция, не имеющая доступа к this, является неизменной и даже не доступна только для чтения по отношению к содержащему ее классу. Но объявление «static» в интерфейсе ISomething также сбивает с толку людей, которые пытаются получить к нему доступ с помощью ISomething.member(), что вызовет ошибку компилятора. Я полагаю, если бы ошибка компилятора была достаточно объяснительной, это было бы лучше, чем пытаться обучать людей использованию нестатических методов для достижения того, что они хотят (по-видимому, в основном фабричные методы), как мы делаем здесь (и это повторялось 3 раза). Время вопросов и ответов на этом сайте), так что это, очевидно, проблема, которая не является интуитивно понятной для многих людей. Мне пришлось подумать над этим некоторое время, чтобы получить правильное понимание.

Способ получить изменяемое статическое поле в интерфейсе - использовать нестатические методы получения и установки в интерфейсе для доступа к этому статическому полю, находящемуся в подклассе. Замечание: очевидно неизменяемая статика может быть объявлена ​​в интерфейсе Java с помощью static final.

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

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

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

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

Однако при желании вы можете сделать это:

public class A {
  public static void methodX() {
  }
}

public class B extends A {
  public static void methodX() {
  }
}

В этом случае у вас есть два класса с двумя разными статическими методами, называемыми methodX ().

Предположим, вы могли бы это сделать; рассмотрим этот пример:

interface Iface {
  public static void thisIsTheMethod();
}

class A implements Iface {

  public static void thisIsTheMethod(){
    system.out.print("I'm class A");
  }

}

class B extends Class A {

  public static void thisIsTheMethod(){
    System.out.print("I'm class B");
  } 
}

SomeClass {

  void doStuff(Iface face) {
    IFace.thisIsTheMethod();
    // now what would/could/should happen here.
  }

}

Что-то, что может быть реализовано, - это статический интерфейс (вместо статического метода в интерфейсе). Все классы, реализующие данный статический интерфейс, должны реализовывать соответствующие статические методы. Вы можете получить статический интерфейс SI из любого класса Clazz, используя

SI si = clazz.getStatic(SI.class); // null if clazz doesn't implement SI
// alternatively if the class is known at compile time
SI si = Someclass.static.SI; // either compiler errror or not null

тогда вы можете позвонить si.method(params). Это было бы полезно (например, для шаблона проектирования фабрики), потому что вы можете получить (или проверить реализацию) реализацию статических методов SI из неизвестного во время компиляции класса! Необходима динамическая отправка, и вы можете переопределить статические методы (если не окончательные) класса, расширив его (при вызове через статический интерфейс). Очевидно, что эти методы могут обращаться только к статическим переменным своего класса.

Хотя я понимаю, что Java 8 решает эту проблему, я подумал, что подключусь к сценарию, над которым я сейчас работаю (заблокирован для использования Java 7), где было бы полезно указать статические методы в интерфейсе.

У меня есть несколько определений перечислений, в которых я определил поля «id» и «displayName» вместе с вспомогательными методами, оценивающими значения по разным причинам. Реализация интерфейса позволяет мне гарантировать наличие методов получения, но не статических вспомогательных методов. Поскольку это перечисление, на самом деле нет чистого способа выгрузить вспомогательные методы в унаследованный абстрактный класс или что-то в этом роде, поэтому методы должны быть определены в самом перечислении. Кроме того, поскольку это перечисление, вы никогда не сможете фактически передать его как экземпляр объекта и рассматривать его как тип интерфейса, но возможность требовать существования статических вспомогательных методов через интерфейс - это то, что мне нравится в он поддерживается в Java 8.

Вот код, иллюстрирующий мою точку зрения.

Определение интерфейса:

public interface IGenericEnum <T extends Enum<T>> {
    String getId();
    String getDisplayName();
    //If I was using Java 8 static helper methods would go here
}

Пример определения одного перечисления:

public enum ExecutionModeType implements IGenericEnum<ExecutionModeType> {
    STANDARD ("Standard", "Standard Mode"),
    DEBUG ("Debug", "Debug Mode");

    String id;
    String displayName;

    //Getter methods
    public String getId() {
        return id;
    }

    public String getDisplayName() {
        return displayName;
    }

    //Constructor
    private ExecutionModeType(String id, String displayName) {
        this.id = id;
        this.displayName = displayName;
    }

    //Helper methods - not enforced by Interface
    public static boolean isValidId(String id) {
        return GenericEnumUtility.isValidId(ExecutionModeType.class, id);
    }

    public static String printIdOptions(String delimiter){
        return GenericEnumUtility.printIdOptions(ExecutionModeType.class, delimiter);
    }

    public static String[] getIdArray(){
        return GenericEnumUtility.getIdArray(ExecutionModeType.class);
    }

    public static ExecutionModeType getById(String id) throws NoSuchObjectException {
        return GenericEnumUtility.getById(ExecutionModeType.class, id);
    }
}

Определение универсальной утилиты перечисления:

public class GenericEnumUtility {
    public static <T extends Enum<T> & IGenericEnum<T>> boolean isValidId(Class<T> enumType, String id) {       
        for(IGenericEnum<T> enumOption : enumType.getEnumConstants()) {
            if(enumOption.getId().equals(id)) {
                return true;
            }
        }

        return false;
    }

    public static <T extends Enum<T> & IGenericEnum<T>> String printIdOptions(Class<T> enumType, String delimiter){
        String ret = "";
        delimiter = delimiter == null ? " " : delimiter;

        int i = 0;
        for(IGenericEnum<T> enumOption : enumType.getEnumConstants()) {
            if(i == 0) {
                ret = enumOption.getId();
            } else {
                ret += delimiter + enumOption.getId();
            }           
            i++;
        }

        return ret;
    }

    public static <T extends Enum<T> & IGenericEnum<T>> String[] getIdArray(Class<T> enumType){
        List<String> idValues = new ArrayList<String>();

        for(IGenericEnum<T> enumOption : enumType.getEnumConstants()) {
            idValues.add(enumOption.getId());
        }

        return idValues.toArray(new String[idValues.size()]);
    }

    @SuppressWarnings("unchecked")
    public static <T extends Enum<T> & IGenericEnum<T>> T getById(Class<T> enumType, String id) throws NoSuchObjectException {
        id = id == null ? "" : id;
        for(IGenericEnum<T> enumOption : enumType.getEnumConstants()) {
            if(id.equals(enumOption.getId())) {
                return (T)enumOption;
            }
        }

        throw new NoSuchObjectException(String.format("ERROR: \"%s\" is not a valid ID. Valid IDs are: %s.", id, printIdOptions(enumType, " , ")));
    }
}

Предположим, что в интерфейсах разрешены статические методы: * Они заставят все реализующие классы объявить этот метод. * Интерфейсы обычно используются через объекты, поэтому единственными эффективными методами для них будут нестатические. * Любой класс, который знает конкретный интерфейс, может вызывать его статические методы. Следовательно, статический метод реализующего класса будет вызываться внизу, но класс вызывающего не знает, какой именно. Как это узнать? У него нет экземпляра, чтобы это догадаться!

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

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

Для этого служат метаклассы. Вы можете попробовать класс Class of Java. Но проблема в том, что Java для этого недостаточно гибкая. Вы не можете объявить метод в объекте класса интерфейса.

Это мета-проблема - когда нужно делать задницу

..бла-бла

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

Чтобы решить эту проблему: ошибка: отсутствует тело метода или объявлено абстрактное static void main (String [] args);

interface I
{
    int x=20;
    void getValue();
    static void main(String[] args){};//Put curly braces 
}
class InterDemo implements I
{
    public void getValue()
    {
    System.out.println(x);
    }
    public static void main(String[] args)
    {
    InterDemo i=new InterDemo();
    i.getValue();   
    }

}

выход: 20

Теперь мы можем использовать статический метод в интерфейсе

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

MyImplClass.myMethod()

тогда вам не нужно объявлять это в интерфейсе. Если вы хотите называть их как

myInstance.myMethod()

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

Интерфейсы позволяют определять контракт между экземпляром класса, реализующего интерфейс, и вызывающим кодом. И java помогает вам быть уверенным, что этот контракт не нарушен, поэтому вы можете положиться на него и не беспокоиться, какой класс реализует этот контракт, достаточно просто «того, кто подписал контракт». В случае статических интерфейсов ваш код

MyImplClass.myMethod()

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

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