Por que não pode definir um método estático em uma interface Java?

https://stackoverflow.com/questions/512877

21-08-2019
|

Pergunta

EDIT:. A partir de Java 8, métodos estáticos agora são permitidos nas interfaces

Aqui está o exemplo:

public interface IXMLizable<T>
{
  static T newInstanceFromXML(Element e);
  Element toXMLElement();
}

Claro que isso não vai funcionar. Mas por que não?

Uma das questões possíveis seriam, o que acontece quando você chama:

IXMLizable.newInstanceFromXML(e);

Neste caso, eu acho que deveria apenas chamar um método vazio (ou seja, {}). Todas as subclasses seriam obrigados a implementar o método estático, de modo que tudo estaria bem ao chamar o método estático. Então por que não é possível?

EDIT: Eu acho que eu estou procurando resposta que é mais profundo do que "porque essa é a maneira Java é".

Existe uma razão tecnológica específica porque os métodos estáticos não podem ser substituídos? Ou seja, por que os designers de Java decidir fazer métodos de instância métodos estáticos overrideable mas não?

EDIT:. O problema com meu projeto é que eu estou tentando usar interfaces para impor uma convenção de codificação

Ou seja, o objetivo da interface é duplo:

Eu quero a interface IXMLizable para permitir-me para converter classes que implementam-lo para elementos XML (usando polimorfismo, bem funciona).
Se alguém quiser fazer uma nova instância de uma classe que implementa a interface IXMLizable, eles sempre sabem que vai haver um construtor estático newInstanceFromXML (Elemento e).

Existe alguma outra maneira de garantir isso, outro do que simplesmente colocar um comentário na interface?

Solução

Java 8 permite métodos de interface estáticos

Com Java 8, interfaces de pode tem métodos estáticos. Eles também podem ter métodos de instância de concreto, mas não campos de instância.

Há realmente duas questões aqui:

Por que, nos velhos tempos, não poderia interfaces de conter métodos estáticos?
Por que métodos não estáticos ser substituído?

Os métodos estáticos em interfaces de

Não houve forte razão técnica pela qual interfaces não poderia ter tido métodos estáticos em versões anteriores. Esta é resumiu bem pelo cartaz de uma questão duplicado. métodos de interface estáticos foram inicialmente considerados como uma pequena mudança de idioma, e então houve uma proposta oficial para adicioná-los em Java 7, mas foi mais tarde caiu devido a complicações imprevistas

Finalmente, Java 8 introduziu métodos de interface estáticos, bem como métodos de instância substituem-able com uma implementação padrão. Eles ainda não podem ter instâncias campos embora. Esses recursos fazem parte do apoio de expressão lambda, e você pode ler mais sobre eles no Parte H de JSR 335.

Overriding métodos estáticos

A resposta à segunda pergunta é um pouco mais complicado.

Os métodos estáticos são solucionáveis ??em tempo de compilação. expedição dinâmica faz sentido para os métodos de instância, onde o compilador não pode determinar o tipo concreto do objecto, e, assim, não é possível resolver o método para invocar. Mas invocar um método estático requer uma classe, e uma vez que a classe é conhecida estaticamente compilação -pelo expedição tempo dinâmico é desnecessário.

Um pouco de fundo sobre como métodos de instância trabalho é necessário para entender o que está acontecendo aqui. Tenho certeza de que a implementação real é bem diferente, mas deixe-me explicar a minha noção de expedição método, que modelos observado comportamento com precisão.

Finja que cada classe tem uma tabela hash que mapeia assinaturas de método (nome e parâmetros tipos) a um pedaço real de código para implementar o método. Quando as tentativas de máquinas virtuais para chamar um método em uma instância, ele consulta o objeto de sua classe e olha-se a assinatura solicitada na tabela da classe. Se um corpo de método é encontrado, ele é invocado. Caso contrário, a classe principal da classe é obtida, e a pesquisa é repetido lá. Esta prossegue até que o método se encontra, ou não há mais classes-mãe que resulta em um NoSuchMethodError.

Se uma superclasse e uma subclasse ambos têm uma entrada em suas tabelas para a mesma assinatura do método, a versão do sub-classe é encontrado pela primeira vez, e a versão da superclasse nunca é usada-esta é uma "substituição".

Agora, suponha que pular a instância do objeto e só começar com uma subclasse. A resolução poderia proceder como acima, dando-lhe uma espécie de método estático "substituível". A resolução pode tudo acontecer em tempo de compilação, no entanto, uma vez que o compilador é a partir de uma classe conhecida, ao invés de esperar até a execução de consultar um objeto de um tipo não especificado para a sua classe. Não há nenhum ponto em "substituir" um método estático desde sempre se pode especificar a classe que contém a versão desejada.

Construtor "interfaces"

Aqui está um pouco mais material para resolver a edição recente para a questão.

Parece que você quer impor efetivamente um método construtor-like para cada implementação de IXMLizable. Esqueça tentar impor isso com uma interface para um minuto, e fingir que você tem algum classes que cumprem este requisito. Como você usá-lo?

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

Foo obj = Foo.newInstanceFromXML(e);

Uma vez que você tem que nomear explicitamente o tipo Foo concreto quando "construir" o novo objeto, o compilador pode verificar se ele realmente tem o método de fábrica necessário. E se isso não acontecer, então o que? Se eu pode implementar uma IXMLizable que falta o "construtor", e eu criar uma instância e passá-lo ao seu código, ele é um IXMLizable com toda a interface necessária.

Construção é parte da implementação, não a interface. Qualquer código que funciona com êxito com a interface não se preocupa com o construtor. Qualquer código que se preocupa com as necessidades do construtor para saber o tipo concreto de qualquer maneira, ea interface pode ser ignorado.

Outras dicas

Isso já foi feita e respondida, aqui

Para duplicar a minha resposta:

Nunca há um ponto de declarar um método estático em uma interface. Eles não podem ser executado pela chamada normal MyInterface.staticMethod (). Se você chamá-los, especificando o MyImplementor.staticMethod classe de execução (), então você deve saber a classe real, por isso é irrelevante se a interface contém ou não.

Mais importante, métodos estáticos nunca são substituídas, e se você tentar fazer:

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

as regras para dizer estática que o método definido no tipo declarado de var deve ser executado. Uma vez que esta é uma interface, isto é impossível.

A razão que você não pode executar "resultado = MyInterface.staticMethod ()" é que ele teria que executar a versão do método definido no MyInterface. Mas não pode haver uma versão definida no MyInterface, porque é uma interface. Ele não tem código por definição.

Enquanto você pode dizer que isso equivale a "porque Java faz isso dessa maneira", na realidade, a decisão é uma consequência lógica de outras decisões de design, também feitos por muito boas razões.

Normalmente, isso é feito usando um padrão de fábrica

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

public interface IXMLizable {
  public Element toXMLElement();
}

Com o advento da Java 8 é possível agora para escrever padrão e estática métodos na interface. docs.oracle/staticMethod

Por exemplo:

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

Resultado : 6

Dica: Chamar um método de interface estática não necessita de ser implementada por qualquer classe. Certamente, isso acontece porque as mesmas regras para métodos estáticos em superclasses aplica-se para métodos estáticos em interfaces.

Como métodos estáticos não pode ser substituído em subclasses, e, portanto, eles não podem ser abstrato. E todos os métodos em uma interface são, de facto , abstrato.

Por que não consigo definir um método estático em uma interface Java?

Na verdade, você pode em Java 8.

De acordo com Java doc :

Um método estático é um método que está associado com a classe em que que é definido, em vez do que com qualquer objecto. Cada instância da classe compartilha seus métodos estáticos

Em Java 8 uma interface pode ter métodos padrão e métodos estáticos . Isto torna mais fácil para nós para organizar métodos auxiliares em nossas bibliotecas. Podemos manter métodos estáticos específico para uma interface na mesma interface em vez de em uma classe separada.

Exemplo de método padrão:

list.sort(ordering);

em vez de

Collections.sort(list, ordering);

Exemplo de método estático (a partir de doc si):

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

Interfaces estão preocupados com o polimorfismo que é inerentemente vinculado a instâncias de objetos, e não classes. Portanto estática não faz sentido no contexto de uma interface.

Em primeiro lugar, todas as decisões de idioma são decisões tomadas pelos criadores de linguagem. Não há nada no mundo da engenharia de software ou linguagem de definição ou de compilador / escrita intérprete que diz que um método estático não pode ser parte de uma interface. Eu criei um par de linguagens e compiladores escritos por eles - tudo é apenas sentar e definir semânticas significativas. Eu diria que a semântica de um método estático em uma interface são notavelmente claro -. Mesmo se o compilador tem a resolução de adiamento do método para executar em tempo

Em segundo lugar, que nós usamos métodos estáticos em todos os meios não é uma razão válida para ter um padrão de interface que inclui métodos estáticos - Eu não posso falar para qualquer um de vocês, mas eu usar métodos estáticos em uma base regular <. / p>

A resposta mais provável correta é que não há necessidade foi percebida, no momento que a linguagem foi definida, por métodos estáticos em interfaces. Java tem crescido muito ao longo dos anos e este é um item que tem, aparentemente, ganhou algum interesse. Que foi olhou para Java 7 indica que a sua subido para um nível de interesse que possam resultar em uma mudança de linguagem. Eu, por exemplo, vai ser feliz quando eu já não têm de instanciar um objeto apenas para que eu possa chamar de meu método getter não-estática para acessar uma variável estática em uma instância de subclasse ...

Os métodos estáticos não são virtuais como métodos de instância, então eu suponho que os designers Java decidiram que não deseja-los em interfaces.

Mas você pode colocar as classes que contêm métodos estáticos dentro interfaces. Você poderia tentar isso!

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

"Existe uma razão particular que os métodos estáticos não pode ser substituído".

Deixe-me voltar a palavra que pergunta para o seu preenchendo as definições.

"Existe uma razão particular que os métodos resolvidos em tempo de compilação não pode ser resolvido em tempo de execução."

Ou, para colocar em mais completamente, Se eu quiser chamar um método sem uma instância, mas sabendo que a classe, como posso tê-lo resolvido com base no exemplo que eu não tenho.

Comentando EDIT: As of Java 8, static methods are now allowed in interfaces.

É certo, métodos estáticos desde Java 8 são permitidas em interfaces, mas o seu exemplo ainda não vai funcionar. Você não pode apenas definir um método estático:. Você tem que implementá-lo ou você vai obter um erro de compilação

Bem, sem genéricos, interfaces de estáticos são inúteis porque todas as chamadas de métodos estáticos são resolvidas em tempo de compilação. Assim, não há nenhum uso real para eles.

Com os genéricos, eles têm uso - com ou sem uma implementação padrão. Obviamente não precisaria ser substituindo e assim por diante. No entanto, o meu palpite é que essa utilização não era muito OO (como as outras respostas apontam obtusely) e, portanto, não foi considerada a pena o esforço que eles necessitam para implementar útil.

Várias respostas têm discutido os problemas com o conceito de métodos estáticos substituível. No entanto, às vezes você se deparar com um padrão onde parece que isso é apenas o que você deseja usar.

Por exemplo, trabalho com uma camada objeto-relacional que tem objectos de valor, mas também tem comandos para manipular os objectos de valor. Por várias razões, cada classe de objeto de valor tem que definir alguns métodos estáticos que permitem o enquadramento localizar a instância de comando. Por exemplo, para criar uma pessoa que você faria:

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

e para carregar uma pessoa pelo ID que você faria

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

Isto é bastante conveniente, no entanto, tem seus problemas; nomeadamente a existência dos métodos estáticos não podem ser aplicadas na interface. Um método estático substituível na interface seria exatamente o que tínhamos necessidade, se só ele poderia trabalhar de alguma forma.

EJBs resolver este problema por ter uma interface inicial; cada objeto sabe como encontrar a sua casa ea casa contém os métodos "estáticas". Desta forma, os métodos "estáticas" pode ser substituído conforme necessário, e você não atravancar o (ele é chamado "Remote") Interface normal com métodos que não se aplicam a uma instância do seu bean. Basta fazer a interface normal de especificar um "getHome) (" método. Retornar uma instância do objeto Home (que poderia ser um singleton, suponho) eo chamador pode executar operações que afetam todos os objetos Person.

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

Todos os métodos em uma interface são explicitamente abstrato e, portanto, você não pode defini-los como estático porque os métodos estáticos não pode ser abstrato.

Uma interface não pode nunca ser dereferenced estaticamente, por exemplo, ISomething.member. Uma interface é sempre desreferenciado através de uma variável que se refere a um exemplo de uma subclasse da interface. Assim, uma referência de interface nunca pode saber qual subclasse se refere a sem uma instância de sua subclasse.

Assim, a aproximação mais próxima de um método estático em uma interface seria um método não-estático que ignora "isto", ou seja, faz membros não o acesso de qualquer não-estáticos da instância. No abstração de baixo nível, cada método não-estático (após pesquisa em qualquer vtable) é realmente apenas uma função com escopo de classe que leva "isto" como um parâmetro formal implícito. Veja objeto singleton do Scala e interoperabilidade com Java como prova desse conceito. E assim cada método estático é uma função com escopo de classe que não tem um "presente" parâmetro. Assim normalmente um método estático pode ser chamado estaticamente, mas como afirmado anteriormente, uma interface não tem nenhuma implementação (é abstrato).

Assim, para obter melhor aproximação para um método estático em uma interface, é a utilização de um método não-estático, em seguida, fazer não acesso qualquer um dos membros de instância não-estáticos. Não haveria nenhum benefício de desempenho possível de outra maneira, porque não há nenhuma maneira de ligação estaticamente (em tempo de compilação) um ISomething.member(). A única vantagem que eu vejo de um método estático em uma interface é que ele não iria entrada (ou seja, ignorar) um implícito "isto" e acesso, assim, não permitir a qualquer um dos membros de instância não-estáticos. Isso iria declarar implicitamente que a função que não acesso "isto", é immutate e nem mesmo somente leitura em relação à sua classe que contém. Mas uma declaração de "estático" em uma ISomething de interface também pessoas confundem que tentaram acessá-lo com ISomething.member() que faria com que um erro do compilador. Suponho que se o erro do compilador era suficientemente explicativo, seria melhor do que tentar educar as pessoas sobre o uso de um método não-estático para realizar o que eles querem (aparentemente principalmente métodos de fábrica), como estamos fazendo aqui (e tem sido repetido para 3 Q & a vezes neste site), por isso é, obviamente, uma questão que não é intuitiva para muitas pessoas. Eu tinha que pensar sobre isso por um tempo para obter o entendimento correto.

A maneira de obter um campo estático mutável em uma interface é get e set métodos uso não-estáticos em uma interface, de acesso que campo estático que na subclasse. Nota, aparentemente estática imutáveis ??podem ser declaradas em uma interface Java com static final.

Interfaces apenas fornecer uma lista de coisas a classe irá fornecer, não uma implementação real dessas coisas, que é o que o seu item estática é.

Se você quiser estática, use uma classe abstrata e herdá-la, caso contrário, remover o estático.

Espero que ajude!

Você não pode definir métodos estáticos em uma interface porque os métodos estáticos pertence a uma classe não uma instância da classe, e as interfaces não são Classes. Leia mais aqui.

No entanto, se você quiser, pode fazer isso:

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

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

Neste caso, o que você tem é de duas classes com 2 métodos estáticos distintas chamadas methodX ().

Suponha que você poderia fazê-lo; Veja este exemplo:

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

}

Algo que poderia ser implementada é a interface estática (em vez de método estático em uma interface). Todas as classes que implementam uma determinada interface estática deve implementar os métodos estáticos correspondentes. Você poderia começar estática interface de SI de qualquer clazz Classe usando

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

então você pode chamar si.method(params). Isso seria útil (para o padrão de design de fábrica, por exemplo) porque você pode obter (ou verificar a implementação de) SI implementação métodos estáticos de uma classe desconhecida tempo de compilação! A expedição dinâmica é necessário e você pode substituir os métodos estáticos (se não final) de uma classe, estendendo-o (quando chamado através da interface estática). Obviamente, esses métodos podem variáveis ??estáticas única de acesso de sua classe.

Enquanto eu percebo que Java 8 resolve esse problema, eu pensei que eu gritei com um cenário que eu estou trabalhando atualmente em (bloqueado em usar Java 7) onde ser capaz de especificar métodos estáticos em uma interface seria útil.

Eu tenho várias definições enum onde eu definidos "id" e campos "displayName" juntamente com métodos auxiliares avaliar os valores por várias razões. Implementação de uma interface permite-me para garantir que os métodos getter estão no lugar, mas não os métodos auxiliares estático. Sendo um enum, não há realmente uma maneira limpa para descarregar os métodos auxiliares para uma classe abstrata herdada ou algo parecido para que os métodos têm de ser definidas no próprio enum. Também porque é uma enumeração, você não iria nunca ser capaz de realmente passá-lo como um objeto instanciado e tratá-lo como o tipo de interface, mas ser capaz de exigir a existência dos métodos auxiliares estáticos através de uma interface é o que eu gosto sobre sendo suportado em Java 8.

O Aqui código ilustrando o meu ponto.

definição Interface:

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

Exemplo de uma definição enum:

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

Generic definição utilidade enum:

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, " , ")));
    }
}

métodos estáticos suponha do Let foram autorizados em interfaces: * Eles forçaria todos as classes que implementam a declarar esse método. * Interfaces normalmente ser usado através de objetos, de modo que os métodos só eficazes sobre aqueles seriam os não-estáticos. * Qualquer classe que sabe uma interface específica poderia invocar seus métodos estáticos. Assim, uma classe método estático de execução seria chamado por baixo, mas a classe invoker não sabe qual. Como sabe disso? Não tem instanciação de adivinhar isso!

Interfaces foram pensados ??para ser usado ao trabalhar com objetos. Desta forma, um objeto é instanciado a partir de uma determinada classe, de modo que este último assunto está resolvido. A classe invocando não precisa saber qual classe particular é porque a instanciação pode ser feito por uma terceira classe. Assim, a classe invocando conhece apenas a interface.

Se queremos que este seja estendido aos métodos estáticos, devemos ter a possibilidade de EEspecifique uma classe implementando antes, em seguida, passar uma referência para a classe de chamada. Isso poderia usar a classe através dos métodos estáticos na interface. Mas qual é o differente entre esta referência e um objeto? Nós só precisamos de um objeto que representa o que era a classe. Agora, o objeto representa a velha classe, e poderia implementar uma nova interface, incluindo os velhos métodos estáticos - esses são agora não-estático.

Metaclasses servir para este propósito. Você pode tentar a Classe classe de Java. Mas o problema é que o Java não é suficiente flexível para isso. Você não pode declarar um método no objeto de classe de uma interface.

Esta é uma questão meta - quando você precisa fazer ass

.. blá blá

de qualquer maneira você tem uma solução fácil - fazer o non-static método com a mesma lógica. Mas então você teria que primeiro criar um objeto para chamar o método.

Para resolver este: Erro: Falta corpo do método, ou abstrato declarar void main (String [] args) estáticos;

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

}

saída: 20

Agora podemos usar método estático em relação

Eu acho que java não tem métodos de interface estáticos, porque você não precisa deles. Você pode pensar que você faz, mas ... Como você usá-los? Se você quiser chamá-los como

MyImplClass.myMethod()

então você não precisa declará-la na interface. Se você quiser chamá-los como

myInstance.myMethod()

então não deve ser estático. Se você está realmente indo para usar primeiro caminho, mas só quer fazer valer cada implementação de ter tal método estático, então é realmente uma convenção de codificação, não é um contrato entre instância que implementa um código de interface e chamando.

Interfaces permitem definir contrato entre instância de classe que implementar o código de interface e chamando. E java ajuda você a ter certeza de que este contrato não é violada, então você pode contar com ele e não se preocupe que implementa classe deste contrato, apenas "alguém que assinou um contrato" é suficiente. Em caso de estática interage seu código

MyImplClass.myMethod()

não confiar no fato de que cada implementação de interface tem este método, por isso você não precisa de java para ajudá-lo para ter certeza com ele.

O que é a necessidade de método estático na interface, métodos estáticos são usados ??basicamente quando você não tem que criar uma instância de todo objeto idéia de interface é de trazer conceitos OOP com a introdução do método estático que você está desviando conceito.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow