Pregunta

EDIT:. A partir de Java 8, métodos estáticos están ahora autorizados en las interfaces

Aquí está el ejemplo:

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

Por supuesto, esto no funcionará. Pero ¿por qué no?

Una de las posibles cuestiones serían, lo que sucede cuando se llama:

IXMLizable.newInstanceFromXML(e);

En este caso, creo que sólo debe llamar a un método vacío (es decir, {}). Todas las subclases se verían obligados a poner en práctica el método estático, por lo que todo estaría bien cuando se llama al método estático. Entonces ¿por qué no es posible?

EDIT: Creo que estoy en busca de respuesta que es más profundo que "porque esa es la forma en que Java es".

¿Hay alguna razón en particular por la tecnológica métodos estáticos no se pueden sobrescribir? Es decir, ¿por qué los diseñadores de Java deciden hacer métodos métodos de instancia overrideable pero no estática?

EDIT:. El problema con mi diseño es que estoy tratando de utilizar las interfaces para hacer cumplir una convención de codificación

Es decir, el objetivo de la interfaz es doble:

  1. Quiero la interfaz IXMLizable para permitir que convierta clases que implementan a elementos XML (utilizando polimorfismo, funciona bien).

  2. Si alguien quiere hacer una nueva instancia de una clase que implementa la interfaz IXMLizable, siempre sabrán que habrá un newInstanceFromXML (elemento E) constructor estático.

¿Hay alguna otra manera de asegurar esto, que no sea sólo poner un comentario en la interfaz?

¿Fue útil?

Solución

Java 8 permisos métodos de interfaz estáticos

Con Java 8, interfaces de pueden tener métodos estáticos. También pueden tener métodos de instancia concreta, pero no campos de instancia.

En realidad, hay dos cuestiones aquí:

  1. ¿Por qué, en los viejos tiempos, no podían contener las interfaces métodos estáticos?
  2. ¿Por qué no se puede invalidar los métodos estáticos?

Los métodos estáticos en las interfaces

No había ninguna razón técnica fuerte por qué interfaces no podrían haber tenido los métodos estáticos en las versiones anteriores. Esta es resumió muy bien por el cartel de una pregunta duplicado. métodos de interfaz estáticos fueron considerados inicialmente como un pequeño cambio de idioma, y luego hubo una propuesta oficial para añadirlos en Java 7, pero fue más tarde caído debido a complicaciones imprevistas

Finalmente, Java 8 introdujo métodos de interfaz estáticas, así como métodos de instancia de anulación en el poder con una implementación por defecto. Ellos todavía no pueden tener campos de instancia sin embargo. Estas características son parte del soporte de expresiones lambda, y se puede leer más sobre ellos en Parte H de JSR 335.

métodos estáticos Sustitución

La respuesta a la segunda pregunta es un poco más complicado.

Los métodos estáticos son resolubles en tiempo de compilación. Asignación dinámica tiene sentido para los métodos de instancia, en el que el compilador no puede determinar el tipo de hormigón del objeto, y, por tanto, no puede resolver el método a invocar. Pero la invocación de un método estático requiere una clase, y dado que se sabe que la clase estáticamente AT-tiempo de compilación dinámica de despacho es innecesaria.

Un poco de historia sobre cómo es necesaria métodos de instancia de trabajo para entender lo que está pasando aquí. Estoy seguro de que la ejecución real es muy diferente, pero permítanme explicar mi idea de expedición método, que los modelos de comportamiento observados con precisión.

pretender que cada clase tiene una tabla hash que mapea firmas de método (nombre y parámetros tipos) a un trozo real de código para implementar el método. Cuando la máquina virtual intenta invocar un método en una instancia, se consulta el objeto de su clase y busca la firma solicitada en la mesa de la clase. Si se encuentra un cuerpo de método, se invoca. De lo contrario, se obtiene la clase padre de la clase, y la búsqueda se repite allí. Este procede hasta que se encuentre el método, o no hay clases-que más padres resulta en un NoSuchMethodError.

Si una superclase y una subclase ambos tienen una entrada en sus tablas para la misma firma del método, la versión de la subclase se encontró por primera vez, y la versión de la superclase no se usa nunca-se trata de una "anulación".

Ahora, supongamos que no tome la instancia de objeto y simplemente empezamos con una subclase. La resolución podría seguir las indicaciones anteriores, que le da una especie de método estático "reemplazable". La resolución puede suceder todo en tiempo de compilación, sin embargo, ya que el compilador es a partir de una clase conocida, en lugar de esperar hasta que el tiempo de ejecución para consultar un objeto de un tipo no especificado para su clase. No hay ningún punto en "anular" un método estático, ya que siempre se puede especificar la clase que contiene la versión deseada.


Constructor "interfaces"

Aquí hay un poco más de material para hacer frente a la reciente edición en cuestión.

Parece que usted quiere mandato de manera eficaz un método constructor similar para cada aplicación de IXMLizable. Olvidarse de tratar de hacer cumplir esto con una interfaz para un minuto, y pretender que usted tiene algunas clases que cumplen este requisito.¿Cómo se usa?

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

Foo obj = Foo.newInstanceFromXML(e);

Ya que tienes que nombrar explícitamente el tipo concreto Foo cuando "construir" el nuevo objeto, el compilador puede verificar que se tiene de hecho el método de fábrica es necesario. Y si no es así, ¿y qué? Si puedo implementar un <=> que carece del "constructor", y crear una instancia y pasarlo a su código, es una <=> con toda la interfaz necesaria.

La construcción es parte de la aplicación, no es la interfaz. Cualquier código que funciona con éxito con la interfaz no se preocupa por el constructor. Cualquier código que se preocupa por el constructor necesita saber el tipo concreto de todos modos, y la interfaz puede ser ignorada.

Otros consejos

Esto ya fue hecha y contestada, aquí

Para duplicar mi respuesta:

No hay nunca un punto a la declaración de un método estático en una interfaz. No pueden ser ejecutadas por el MyInterface.staticMethod llamada normal (). Si usted los llama mediante la especificación de la clase que implementa MyImplementor.staticMethod (), entonces usted debe saber la clase real, por lo que es irrelevante si la interfaz contiene o no.

Más importante aún, los métodos estáticos no se anulan, y si se intenta hacer:

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

las reglas para estática dicen que el método definido en el tipo declarado de var debe ser ejecutado. Dado que esta es una interfaz, esto es imposible.

La razón por la que no se puede ejecutar "número = MyInterface.staticMethod ()" es que tendría que ejecutar la versión del método definido en MyInterface. Pero no puede haber una versión definida en MyInterface, porque es una interfaz. No tiene código por definición.

Si bien se puede decir que esto equivale a "porque Java lo hace de esa manera", en realidad, la decisión es una consecuencia lógica de otras decisiones de diseño, también hecho por muy buenas razones.

Normalmente esto se hace usando un patrón de fábrica

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

public interface IXMLizable {
  public Element toXMLElement();
}

Con la llegada de Java 8 es posible ahora escribir por defecto y estáticas métodos de interfaz. docs.oracle/staticMethod

Por ejemplo:

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

Consejo: Llamar a un método de interfaz estática no requiere ser implementado por cualquier clase. Sin duda, esto se debe a que las mismas reglas para los métodos estáticos en superclases se aplica para los métodos estáticos en las interfaces.

Debido a métodos estáticos no se pueden sustituir en las subclases, y por lo tanto no pueden ser abstracta. Y todos los métodos en una interfaz son, de facto , abstracto.

  

Por qué no puedo definir un método estático en una interfaz Java?

En realidad se puede en Java 8.

Según Java doc :

  

Un método estático es un método que se asocia con la clase en la cual   se define más bien que con cualquier objeto. Cada instancia de la clase   comparte sus métodos estáticos

En Java 8 una interfaz puede tener métodos predeterminados y métodos estáticos . Esto hace que sea más fácil para nosotros organizar los métodos de ayuda en nuestras bibliotecas. Podemos mantener los métodos estáticos específicos de una interfaz en la misma interfaz en lugar de en una clase separada.

Ejemplo de método por defecto:

list.sort(ordering);

en lugar de

Collections.sort(list, ordering);

Ejemplo de método estático (de doc sí mismo):

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 se ocupan de polimorfismo que está intrínsecamente ligada a instancias de objeto, no clases. Por lo tanto estática no tiene sentido en el contexto de una interfaz.

En primer lugar, todas las decisiones del lenguaje son las decisiones tomadas por los creadores del lenguaje. No hay nada en el mundo de la ingeniería de software o definir el lenguaje escrito o compilador / intérprete que dice que un método estático no puede ser parte de una interfaz. He creado un par de lenguajes y compiladores escritas para ellos - Todo esto es sólo sentarse y definir una semántica significativa. Yo diría que la semántica de un método estático en una interfaz son notablemente clara -. Incluso si el compilador tiene que diferir la resolución del método de tiempo de ejecución

En segundo lugar, que utilizamos métodos estáticos en absoluto significa que hay una razón válida para tener un patrón de interfaz que incluye métodos estáticos -. No puedo hablar por cualquiera de ustedes, pero yo utilizamos métodos estáticos sobre una base regular

La respuesta más probable es correcto es que no hay necesidad fue percibida, en el momento en que se definió el lenguaje, los métodos estáticos en las interfaces. Java ha crecido mucho durante los últimos años y este es un elemento que aparentemente ha ganado algo de interés. Que se miraba para Java 7 indica que su elevado a un nivel de interés que puedan resultar en un cambio de idioma. Yo, por ejemplo, a ser feliz cuando yo ya no tengo que crear una instancia de un objeto tan puedo llamar a mi método getter no estático para acceder a una variable estática en una instancia de la subclase ...

Los métodos estáticos no son virtuales como métodos de instancia así que supongo que los diseñadores de Java decidieron que no quieren que en las interfaces.

Pero puedes poner las clases que contienen métodos estáticos dentro de las interfaces. Usted podría intentar eso!

public interface Test {
    static class Inner {
        public static Object get() {
            return 0;
        }
    }
}
  • "¿Hay alguna razón en particular que los métodos estáticos no pueden ser anulados".

Déjame volver a palabra que pregunta para su rellenando las definiciones.

  • "¿Hay alguna razón en particular que los métodos resueltos en tiempo de compilación no se pueden resolver en tiempo de ejecución."

O, para decirlo en forma más completa, si quiero llamar a un método sin un ejemplo, pero sabiendo la clase, ¿cómo puedo tener RESUELVESE basa en la instancia que no tengo.

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

Está bien, ya que los métodos estáticos de Java 8 están permitidos en las interfaces, pero su ejemplo todavía no funcionará. No se puede simplemente definir un método estático:. Tienes que ponerlo en práctica o se obtendrá un error de compilación

Bueno, sin genéricos, las interfaces estáticas son inútiles porque todas las llamadas a métodos estáticos se resuelven en tiempo de compilación. Por lo tanto, no hay ninguna utilidad real para ellos.

Con los genéricos, tienen uso - con o sin una implementación por defecto. Obviamente no tendría que ser de primer orden y así sucesivamente. Sin embargo, mi opinión es que tal uso no era muy OO (como las otras respuestas señalan obtuso) y por lo tanto no se consideró la pena el esfuerzo que habían requieren para poner en práctica de manera útil.

Varias respuestas han discutido los problemas con el concepto de métodos estáticos reemplazables. Sin embargo a veces se encuentra con un patrón donde parece que eso es lo que desea utilizar.

Por ejemplo, trabajo con una capa de objeto-relacional que tiene objetos de valor, pero también tiene comandos para la manipulación de los objetos de valor. Por diversas razones, cada clase de objeto de valor tiene que definir algunos métodos estáticos que permiten al marco encontrar la instancia de comando. Por ejemplo, para crear una persona que haría:

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

y cargar a una persona por ID que haría

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

Esto es bastante conveniente, sin embargo, tiene sus problemas; en particular, la existencia de los métodos estáticos no puede ser ejecutada en la interfaz. Un método estático reemplazable en la interfaz sería exactamente lo que íbamos a necesitar, aunque sólo podría funcionar de alguna manera.

EJB resolver este problema por tener una interfaz de inicio; cada objeto sabe cómo encontrar su hogar y el hogar contiene los métodos "estáticos". De esta manera los métodos "estáticos" se puede reemplazar, según sea necesario, y no saturar la interfaz normal (que se llama "a distancia") con métodos que no se aplican a una instancia de bean. Acaba de hacer la interfaz normal de especificar un método "getHome ()". Devolver una instancia del objeto principal (que podría ser un producto único, supongo) y la persona que llama puede realizar operaciones que afectan a todos los objetos Person.

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

Todos los métodos en una interfaz son explícitamente abstracto y, por tanto, no se puede definir como estática, porque los métodos estáticos no pueden ser abstractos.

Una interfaz nunca puede ser elimina la referencia de forma estática, por ejemplo, ISomething.member. Una interfaz es siempre elimina la referencia a través de una variable que hace referencia a una instancia de una subclase de la interfaz. Por lo tanto, una referencia de interfaz nunca puede saber que la subclase se refiere a sin una instancia de su subclase.

Así, la aproximación más cercana a un método estático en una interfaz sería un método no estático que ignora "este", es decir, no accede a todos los miembros no estáticos de la instancia. En la abstracción de bajo nivel, todos los métodos no estáticos (después de las operaciones de búsqueda en cualquier vtable) es en realidad una función con ámbito de clase que se lleva a "esto" como un parámetro formal implícita. Ver Scala y la interoperabilidad con Java como evidencia de ese concepto. Y así cada método estático es una función con ámbito de clase que no tiene un "este" parámetro. Por lo tanto normalmente un método estático puede ser llamado estáticamente, pero como se ha indicado anteriormente, una interfaz no tiene ninguna aplicación (es resumen).

Por lo tanto para obtener más parecido a un método estático en una interfaz, es utilizar un método no estático, entonces no acceder a cualquiera de los miembros de instancia no estáticos. No habría ningún beneficio de rendimiento posible de otra manera, porque no hay manera de enlazar estáticamente (en tiempo de compilación) un ISomething.member(). El único beneficio que veo de un método estático en una interfaz es que sería no de entrada (es decir, ignorar) un implícito "este" y por lo tanto no permitir el acceso a cualquiera de los miembros de instancia no estáticos. Esto sería declarar implícitamente que la función que no accede a "este", es immutate y ni siquiera de sólo lectura con respecto a su clase que contiene. Pero una declaración de "estática" en una interfaz ISomething también podría confundir a la gente que intentó acceder a ella con static final cual provocaría un error de compilación. Supongo que si el error del compilador es suficientemente explicativa, sería mejor que tratar de educar a la gente sobre el uso de un método no estático para lograr lo que quieren (al parecer en su mayoría métodos de fábrica), como lo estamos haciendo aquí (y se ha repetido durante 3 Q & a veces en este sitio), por lo que es obviamente una cuestión que no es intuitivo para muchas personas. Tenía que pensar en ello durante un tiempo para conseguir la correcta comprensión.

La manera de obtener un campo estático mutable en una interfaz es utilizar getter y setter métodos no estáticos en una interfaz, para acceder a ese campo estático que en la subclase. Nota al margen, aparentemente inmutables estática puede declararse de una interfaz Java con <=>.

Interfaces sólo proporciona una lista de las cosas una clase proporcionará, no una implementación real de las cosas, que es lo que su artículo es estática.

Si desea estática, utilice una clase abstracta y heredad la tierra, de lo contrario, retire la estática.

Espero que ayude!

No se puede definir métodos estáticos en una interfaz porque los métodos estáticos pertenece a una clase no a una instancia de clase, y las interfaces no son clases. Lea más aquí.

Sin embargo, si se desea se puede hacer esto:

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

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

En este caso lo que se tiene es de dos clases con 2 métodos estáticos distintas llamadas methodX ().

Supongamos que podía hacerlo; Considere este ejemplo:

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 podría ser implementada es la interfaz estática (en lugar de método estático en una interfaz). Todas las clases que implementan una interfaz estática dada deben poner en práctica los métodos estáticos correspondientes. Se podía conseguir SI interfaz estático de cualquier clase clazz utilizando

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

A continuación, se puede llamar si.method(params). Esto sería útil (para el patrón de diseño de la fábrica, por ejemplo), ya que se puede obtener (o comprobar la aplicación de) SI aplicación métodos estáticos de una clase desconocida tiempo de compilación! Un despacho dinámico es necesario y se puede anular los métodos estáticos (si no final) de una clase extendiéndolo (cuando se llama a través de la interfaz estática). Obviamente, estos métodos sólo pueden acceder a las variables estáticas de su clase.

Mientras me di cuenta de que Java 8 resuelve este problema, pensé que interrumpiría con un escenario Actualmente estoy trabajando en (encerrado en el uso de Java 7) en el que ser capaz de especificar los métodos estáticos en una interfaz sería de gran ayuda.

Tengo varias definiciones de enumeración, donde he definido campos "displayName" "ID" y junto con los métodos de ayuda evaluar los valores por varias razones. La implementación de una interfaz me permite garantizar que los métodos getter están en su lugar, pero no los métodos de ayuda estáticas. Al ser una enumeración, en realidad no es una forma limpia para descargar los métodos de ayuda en una clase abstracta heredada o algo por el estilo por lo que los métodos tienen que ser definidas en la propia enumeración. También porque es una enumeración, usted nunca será capaz de pasar en realidad como un objeto de instancia y tratarlo como el tipo de interfaz, pero ser capaz de requerir la existencia de los métodos estáticos de ayuda a través de una interfaz es lo que me gusta que se apoya en Java 8.

Aquí está el código que ilustra mi punto.

Definición de interfaz:

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

Ejemplo de definición de una 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);
    }
}

Genérico definición utilidad enumeración:

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

Supongamos métodos estáticos fueron permitidos en las interfaces: * Se obligaría a todas las clases que implementan para declarar ese método. * Interfaces normalmente serían utilizadas a través de objetos, por lo que los únicos métodos eficaces sobre los que serían los que no estáticos. * Cualquier clase que sabe una interfaz en particular podría invocar sus métodos estáticos. De ahí método estático de una clase que implementa sería llamado por debajo, pero la clase invocador no sabe cuál. ¿Cómo saberlo? No tiene ninguna ejemplificación de adivinar eso!

Se pensaba

Interfaces para ser usado cuando se trabaja con objetos. De esta manera, se crea una instancia de un objeto de una clase en particular, por lo que esta última cuestión se resuelve. La clase de invocación no necesita saber qué clase particular, se debe a la creación de instancias puede ser hecho por una tercera clase. Así la clase invocación sólo conoce la interfaz.

Si queremos que esto se extienda a métodos estáticos, deberíamos tener la posibilidad de Especificar una clase que implementa antes, a continuación, pasar una referencia a la clase de invocación. Esto podría utilizar la clase a través de los métodos estáticos en la interfaz. Pero ¿cuál es la differente entre esta referencia y un objeto? Sólo tenemos un objeto que representa lo que era la clase. Ahora, el objeto representa la clase de edad, y podría poner en práctica una nueva interfaz que incluye los antiguos métodos estáticos - los que ahora son no estático.

metaclases sirven para este propósito. Usted puede tratar de la Clase de clase de Java. Pero el problema es que Java no es lo suficientemente flexible como para esto. No se puede declarar un método en la clase de objeto de una interfaz.

Este es un tema meta - cuando se necesita hacer culo

.. bla bla

de todos modos tiene una fácil solución - haciendo que el método no estático con la misma lógica. Pero entonces tendría que crear primero un objeto para llamar al método.

Para resolver este: Error: falta el cuerpo del método, o declarar abstracta         void Main (args String []) estáticas;

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

}

salida: 20

Ahora podemos usar el método estático en la interfaz

Creo que java no tiene métodos de interfaz estáticas, ya que no los necesita. Usted puede pensar que hacer, pero ... Cómo los usarías? Si desea llamar a ellos como

MyImplClass.myMethod()

a continuación, no es necesario declarar en la interfaz. Si desea llamar a ellos como

myInstance.myMethod()

entonces no debería ser estática. Si en realidad se va a utilizar la primera forma, sino que sólo quiere cumplir cada aplicación para tener tal método estático, entonces es realmente una convención de codificación, no un contrato entre el ejemplo que implementa una interfaz y código de llamada.

Interfaces le permiten definir contrato entre instancia de la clase que implementa la interfaz y el código de llamada. Y Java ayuda a estar seguro de que este contrato no es violada, lo que puede confiar en él y no preocuparse de lo clase implementa este contrato, sólo "alguien que firmó un contrato" es suficiente. En el caso de interfaces estáticas su código

<*>

no se basa en el hecho de que cada implementación de la interfaz tiene este método, por lo que no es necesario java para ayudarle a estar seguro con él.

¿Cuál es la necesidad del método estático en la interfaz, los métodos estáticos se utilizan, básicamente, cuando no se tiene que crear una instancia de objeto toda idea de interfaz es traer a los conceptos de POO con la introducción del método estático que está desviando de concepto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top