Ответ 1

Java 8 допускает статические методы интерфейса

В Java 8 интерфейсы могут иметь статические методы. Они также могут иметь конкретные методы экземпляра, но не поля экземпляра.

Здесь действительно два вопроса:

1. Почему в старые добрые времена интерфейсы не могли содержать статические методы?
2. Почему статические методы не могут быть переопределены?

Статические методы в интерфейсах

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

Наконец, Java 8 представила статические методы интерфейса, а также перезаписываемые методы экземпляров с реализацией по умолчанию. Они все еще не могут иметь поля экземпляра, хотя. Эти функции являются частью поддержки лямбда-выражений, и вы можете прочитать больше о них в Части H JSR 335.

Переопределение статических методов

Ответ на второй вопрос немного сложнее.

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

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

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

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

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

Конструктор "Интерфейс"

Здесь немного больше материала, чтобы обратиться к недавнему редактированию вопроса.

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

class Foo implements IXMLizable<Foo> {
  public static Foo newInstanceFromXML(Element e) { ... }
}

Foo obj = Foo.newInstanceFromXML(e);

Поскольку вы должны явно указать конкретный тип Foo при "создании" нового объекта, компилятор может убедиться, что у него действительно есть необходимый фабричный метод. А если нет, ну и что? Если я могу реализовать IXMLizable котором отсутствует "конструктор", и создать экземпляр и передать его в ваш код, это IXMLizable со всем необходимым интерфейсом.

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

Обычно это выполняется с использованием шаблона Factory

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

public interface IXMLizable {
  public Element toXMLElement();
}

Ответ 4

С появлением 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

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

Ответ 5

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

Ответ 6

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

На самом деле вы можете в Java 8.

Согласно документу Java:

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

В 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));
    }    
}

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

• "Есть ли особая причина, почему статические методы нельзя переопределить".

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

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

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

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

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

и загрузить идентификатор Person by ID, который вы делаете

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

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

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

Ответ 14

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

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

Ответ 15

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

Таким образом, ближайшим приближением к статическому методу в интерфейсе будет нестатический метод, который игнорирует "this", то есть не получает доступа к каким-либо нестатическим членам экземпляра. При низкоуровневой абстракции каждый нестатический метод (после поиска в любом vtable) на самом деле является просто функцией с областью класса, которая принимает "this" как неявный формальный параметр. В качестве доказательства этой концепции смотрите Scala singleton object и совместимость с Java. И таким образом, каждый статический метод является функцией с областью класса, которая не принимает параметр "this". Таким образом, обычно статический метод можно назвать статически, но, как было сказано ранее, интерфейс не имеет реализации (является абстрактным).

Таким образом, чтобы получить самое близкое приближение к статическому методу в интерфейсе, нужно использовать нестатический метод, а затем не обращаться к любому из нестатических членов экземпляра. Не будет никакой возможной выгоды от производительности любым другим способом, потому что нет способа статически связать (во время компиляции) a ISomething.member(). Единственное преимущество, которое я вижу в статическом методе в интерфейсе, заключается в том, что он не будет вводить (т.е. Игнорировать) неявный "this" и тем самым запрещать доступ к любому из нестатических членов экземпляра. Это неявно объявляло бы, что функция, которая не имеет доступа к "this", является неизменной и даже не readonly относительно ее содержащего класса. Но объявление "статического" в интерфейсе ISomething также путало бы людей, которые пытались получить к нему доступ с помощью ISomething.member(), которые могли бы вызвать ошибку компилятора. Я полагаю, что если ошибка компилятора была достаточно объяснительной, было бы лучше, чем пытаться обучать людей использованию нестатического метода для выполнения того, что они хотят (по-видимому, главным образом, методов factory), как мы это делаем (и повторяется за 3 Q & A раз на этом сайте), поэтому это, очевидно, проблема, которая не является интуитивной для многих людей. Я должен был подумать об этом некоторое время, чтобы получить правильное понимание.

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

Ответ 16

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

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

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

Ответ 17

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

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

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

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

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

Ответ 18

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

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.
  }

}

Ответ 19

Что-то, что может быть реализовано, - это статический интерфейс (вместо статического метода в интерфейсе). Все классы, реализующие данный статический интерфейс, должны реализовывать соответствующие статические методы. Вы можете получить статический интерфейс 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). Это было бы полезно (например, для шаблона factory), потому что вы можете реализовать (или проверить реализацию) внедрение статических методов SI из неизвестного класса времени компиляции! Динамическая отправка необходима, и вы можете переопределить статические методы (если не окончательные) класса путем его расширения (при вызове через статический интерфейс). Очевидно, что эти методы могут получить доступ только к статическим переменным своего класса.

Ответ 20

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

У меня есть несколько определений перечислений, где я определил поля "id" и "displayName" вместе со вспомогательными методами, оценивая значения по различным причинам. Внедрение интерфейса позволяет мне гарантировать, что методы геттера находятся на месте, но не статические вспомогательные методы. Являясь переименованием, действительно нет чистого способа разгрузить вспомогательные методы в унаследованный абстрактный класс или что-то подобное, поэтому методы должны быть определены в самом перечислении. Кроме того, поскольку это переименование, вы никогда не сможете передавать его как объект instanced и рассматривать его как тип интерфейса, но возможность требовать существования статических вспомогательных методов через интерфейс - это то, что мне нравится он поддерживается в 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, " , ")));
    }
}

Ответ 21

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

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

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

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

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

.. бла-бла

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

Ответ 22

Чтобы решить эту проблему: ошибка: отсутствует тело метода или объявить реферат       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

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

Ответ 23

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

MyImplClass.myMethod()

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

myInstance.myMethod()

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

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

MyImplClass.myMethod()

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

Ответ 24

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