Pourquoi ne puis-je pas définir une méthode statique dans une interface Java?

Voici l’exemple:

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

Bien sûr, cela ne fonctionnera pas. Mais pourquoi pas?

Un des problèmes possibles serait, que se passe-t-il lorsque vous appelez:

 IXMLizable.newInstanceFromXML(e); 

Dans ce cas, je pense qu’il devrait simplement appeler une méthode vide (c’est-à-dire {}). Toutes les sous-classes seraient obligées d’implémenter la méthode statique, alors elles seraient toutes correctes lors de l’appel de la méthode statique. Alors, pourquoi n’est-ce pas possible?

EDIT: Je pense que je cherche une réponse plus profonde que “parce que c’est comme ça que Java est”.

Y a-t-il une raison technologique particulière pour laquelle les méthodes statiques ne peuvent pas être écrasées? C’est-à-dire pourquoi les concepteurs de Java ont-ils décidé de rendre les méthodes d’instance remplaçables mais pas les méthodes statiques?

EDIT: Le problème avec ma conception est que j’essaie d’utiliser des interfaces pour appliquer une convention de codage.

C’est-à-dire que le but de l’interface est double:

  1. Je veux que l’interface IXMLizable me permette de convertir les classes qui l’implémentent en éléments XML (en utilisant le polymorphism, ça marche bien).

  2. Si quelqu’un veut créer une nouvelle instance d’une classe qui implémente l’interface IXMLizable, il saura toujours qu’il y aura un constructeur statique newInstanceFromXML (Element e).

Y a-t-il un autre moyen de garantir cela, si ce n’est que de mettre un commentaire dans l’interface?

EDIT: Depuis Java 8, les méthodes statiques sont désormais autorisées dans les interfaces.

Java 8 autorise les méthodes d’interface statique

Avec Java 8, les interfaces peuvent avoir des méthodes statiques. Ils peuvent également avoir des méthodes d’instance concrètes, mais pas de champs d’instance.

Il y a vraiment deux questions ici:

  1. Pourquoi, dans le mauvais vieux temps, les interfaces ne pouvaient-elles pas contenir des méthodes statiques?
  2. Pourquoi les méthodes statiques ne peuvent-elles pas être remplacées?

Méthodes statiques dans les interfaces

Il n’y avait aucune raison technique forte pour laquelle les interfaces ne pouvaient pas avoir des méthodes statiques dans les versions précédentes. Cela se résume bien par l’affiche d’une question en double. Les méthodes d’interface statique étaient initialement considérées comme un petit changement de langage, puis il y avait une proposition officielle pour les append dans Java 7, mais elle a été abandonnée ultérieurement en raison de complications imprévues.

Enfin, Java 8 a introduit des méthodes d’interface statique, ainsi que des méthodes d’instance remplaçables avec une implémentation par défaut. Ils ne peuvent toujours pas avoir de champs d’instance. Ces fonctionnalités font partie de la prise en charge de l’expression lambda, et vous pouvez en savoir plus à ce sujet dans la partie H du JSR 335.

Remplacer les méthodes statiques

La réponse à la deuxième question est un peu plus compliquée.

Les méthodes statiques peuvent être résolues au moment de la compilation. La répartition dynamic a un sens pour les méthodes d’instance, où le compilateur ne peut pas déterminer le type concret de l’object et ne peut donc pas résoudre la méthode à appeler. Mais invoquer une méthode statique nécessite une classe et, comme cette classe est connue statiquement (au moment de la compilation), la répartition dynamic est inutile.

Un peu d’information sur le fonctionnement des méthodes d’instance est nécessaire pour comprendre ce qui se passe ici. Je suis sûr que la mise en œuvre est très différente, mais permettez-moi d’expliquer la notion de répartition des méthodes, qui modélise avec précision le comportement observé.

Imaginez que chaque classe possède une table de hachage qui mappe les signatures de méthode (noms et types de parameters) sur un bloc de code réel pour implémenter la méthode. Lorsque la machine virtuelle tente d’appeler une méthode sur une instance, elle interroge l’object pour connaître sa classe et recherche la signature demandée dans la table de la classe. Si un corps de méthode est trouvé, il est appelé. Sinon, la classe parente de la classe est obtenue et la recherche y est répétée. Cela se poursuit jusqu’à ce que la méthode soit trouvée ou qu’il n’y ait plus de classes parentes, ce qui entraîne une NoSuchMethodError .

Si une super-classe et une sous-classe ont toutes deux une entrée dans leurs tables pour la même signature de méthode, la version de la sous-classe est rencontrée en premier, et la version de la super-classe n’est jamais utilisée.

Maintenant, supposons que nous ignorions l’instance d’object et commençons simplement par une sous-classe. La résolution pourrait procéder comme ci-dessus, en vous donnant une sorte de méthode statique “remplaçable”. La résolution peut cependant se produire au moment de la compilation, car le compilateur démarre à partir d’une classe connue, au lieu d’attendre l’exécution pour interroger un object d’un type non spécifié pour sa classe. Il ne sert à rien de “remplacer” une méthode statique car on peut toujours spécifier la classe qui contient la version souhaitée.


Constructeur “interfaces”

Voici un peu plus de matériel pour aborder le récent assembly de la question.

Il semble que vous souhaitiez imposer une méthode de type constructeur pour chaque implémentation de IXMLizable . Oubliez d’essayer d’appliquer cela avec une interface pendant une minute, et prétendez que vous avez des classes qui répondent à cette exigence. Comment l’utiliseriez-vous?

 class Foo implements IXMLizable { public static Foo newInstanceFromXML(Element e) { ... } } Foo obj = Foo.newInstanceFromXML(e); 

Comme vous devez explicitement nommer le type concret Foo lors de la “construction” du nouvel object, le compilateur peut vérifier qu’il possède bien la méthode d’usine nécessaire. Et si ce n’est pas le cas, alors quoi? Si je peux implémenter un IXMLizable le “constructeur”, et que je crée une instance et que je la passe à votre code, c’est un IXMLizable avec toutes les interfaces nécessaires.

La construction fait partie de la mise en œuvre, pas de l’interface. Tout code qui fonctionne correctement avec l’interface ne se soucie pas du constructeur. Tout code qui concerne le constructeur doit de toute façon connaître le type concret, et l’interface peut être ignorée.

Cela a déjà été demandé et répondu, ici

Pour dupliquer ma réponse:

Il n’y a jamais de sens à déclarer une méthode statique dans une interface. Ils ne peuvent pas être exécutés par l’appel normal MyInterface.staticMethod (). Si vous les appelez en spécifiant la classe d’implémentation MyImplementor.staticMethod (), vous devez connaître la classe réelle, peu importe que l’interface le contienne ou non.

Plus important encore, les méthodes statiques ne sont jamais remplacées et si vous essayez de le faire:

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

les règles pour statique indiquent que la méthode définie dans le type déclaré de var doit être exécutée. Comme il s’agit d’une interface, c’est impossible.

La raison pour laquelle vous ne pouvez pas exécuter “result = MyInterface.staticMethod ()” est qu’il devrait exécuter la version de la méthode définie dans MyInterface. Mais il ne peut pas y avoir de version définie dans MyInterface, car c’est une interface. Il n’a pas de code par définition.

Bien que vous puissiez dire que cela signifie “parce que Java le fait de cette façon”, la décision est en réalité une conséquence logique des autres décisions de conception, également sockets pour une très bonne raison.

Normalement, cela se fait en utilisant un motif Factory

 public interface IXMLizableFactory { public T newInstanceFromXML(Element e); } public interface IXMLizable { public Element toXMLElement(); } 

Avec l’avènement de Java 8, il est désormais possible d’écrire des méthodes par défaut et des méthodes statiques dans l’interface. docs.oracle/staticMethod

Par exemple:

 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(Ssortingng[] args) { int result = Arithmetic.multiply(2, 3); System.out.println(result); } } 

Résultat : 6

CONSEIL: L’ appel d’une méthode d’interface statique ne nécessite pas d’être implémenté par une classe. Cela se produit certainement parce que les mêmes règles pour les méthodes statiques dans les superclasses s’appliquent aux méthodes statiques sur les interfaces.

Parce que les méthodes statiques ne peuvent pas être remplacées dans les sous-classes, elles ne peuvent donc pas être abstraites. Et toutes les méthodes d’une interface sont, de facto , abstraites.

Pourquoi ne puis-je pas définir une méthode statique dans une interface Java?

En fait, vous pouvez en Java 8.

Selon Java doc :

Une méthode statique est une méthode associée à la classe dans laquelle elle est définie et non à un object. Chaque instance de la classe partage ses méthodes statiques

Dans Java 8, une interface peut avoir des méthodes par défaut et des méthodes statiques . Cela facilite l’organisation des méthodes d’assistance dans nos bibliothèques. Nous pouvons garder des méthodes statiques spécifiques à une interface dans la même interface plutôt que dans une classe séparée.

Exemple de méthode par défaut:

 list.sort(ordering); 

au lieu de

 Collections.sort(list, ordering); 

Exemple de méthode statique (à partir de doc lui-même):

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

Premièrement, toutes les décisions linguistiques sont des décisions sockets par les créateurs de langues. Il n’y a rien dans le monde du génie logiciel ou de la définition de langage ou de l’écriture de compilateur / interprète qui dit qu’une méthode statique ne peut pas faire partie d’une interface. J’ai créé quelques langages et des compilateurs écrits pour eux – tout est juste assis et définissant une sémantique significative. Je dirais que la sémantique d’une méthode statique dans une interface est remarquablement claire – même si le compilateur doit différer la résolution de la méthode à l’exécution.

Deuxièmement, l’utilisation de méthodes statiques signifie qu’il existe une raison valable d’avoir un modèle d’interface incluant des méthodes statiques – je ne peux parler pour aucun d’entre vous, mais j’utilise régulièrement des méthodes statiques.

La réponse correcte la plus probable est qu’il n’y avait pas de besoin perçu, au moment où la langue a été définie, pour les méthodes statiques dans les interfaces. Java a beaucoup évolué au fil des ans et cet article a apparemment suscité un certain intérêt. Le fait que Java 7 ait été examiné indique qu’il a atteint un niveau d’intérêt susceptible d’entraîner un changement de langage. Pour ma part, je serai heureux de ne plus avoir à instancier un object pour pouvoir appeler ma méthode getter non statique pour accéder à une variable statique dans une instance de sous-classe …

Les interfaces concernent le polymorphism qui est insortingnsèquement lié aux instances d’object, et non aux classes. Par conséquent, le statique n’a pas de sens dans le contexte d’une interface.

  • “Existe-t-il une raison particulière pour laquelle les méthodes statiques ne peuvent pas être remplacées”.

Permettez-moi de reformuler cette question en remplissant les définitions.

  • “Existe-t-il une raison particulière pour laquelle les méthodes résolues au moment de la compilation ne peuvent pas être résolues à l’exécution.”

Ou, plus complètement, si je veux appeler une méthode sans instance, mais connaissant la classe, comment puis-je la résoudre en fonction de l’instance que je n’ai pas.

Les méthodes statiques ne sont pas des méthodes d’instance virtuelles, donc je suppose que les concepteurs Java ont décidé qu’ils n’en voulaient pas dans les interfaces.

Mais vous pouvez mettre des classes contenant des méthodes statiques dans les interfaces. Vous pourriez essayer ça!

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

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

Les méthodes statiques depuis Java 8 sont autorisées dans les interfaces, mais votre exemple ne fonctionnera toujours pas. Vous ne pouvez pas simplement définir une méthode statique: vous devez l’implémenter ou vous obtiendrez une erreur de compilation.

Eh bien, sans les génériques, les interfaces statiques sont inutiles car tous les appels de méthodes statiques sont résolus au moment de la compilation. Donc, ils ne sont pas vraiment utiles.

Avec les génériques, ils utilisent – avec ou sans implémentation par défaut. De toute évidence, il faudrait que cela soit prioritaire et ainsi de suite. Cependant, je pense que cet usage n’était pas très OO (comme le font remarquer les autres réponses) et n’a donc pas été considéré comme intéressant les efforts qu’il aurait fallu mettre en œuvre de manière utile.

Plusieurs réponses ont discuté des problèmes avec le concept de méthodes statiques remplaçables. Cependant, il arrive parfois que vous renconsortingez un modèle qui semble correspondre à ce que vous souhaitez utiliser.

Par exemple, je travaille avec une couche relationnelle d’object qui a des objects de valeur, mais qui possède également des commandes pour manipuler les objects de valeur. Pour diverses raisons, chaque classe d’object de valeur doit définir des méthodes statiques permettant au framework de trouver l’instance de commande. Par exemple, pour créer une personne que vous feriez:

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

et pour charger une personne par identifiant que vous feriez

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

C’est assez pratique, cependant il a ses problèmes; notamment l’existence des méthodes statiques ne peuvent pas être appliquées dans l’interface. Une méthode statique remplaçable dans l’interface serait exactement ce dont nous aurions besoin, si seulement cela pouvait fonctionner d’une manière ou d’une autre.

Les EJB résolvent ce problème en ayant une interface Home; chaque object sait comment trouver sa maison et la maison contient les méthodes “statiques”. De cette façon, les méthodes “statiques” peuvent être surchargées si nécessaire, et vous n’encombrez pas l’interface normale (appelée “Remote”) avec les méthodes qui ne s’appliquent pas à une instance de votre bean. Il suffit de faire en sorte que l’interface normale spécifie une méthode “getHome ()”. Renvoie une instance de l’object Home (qui peut être un singleton, je suppose) et l’appelant peut effectuer des opérations qui affectent tous les objects Person.

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

Toutes les méthodes d’une interface sont explicitement abstraites et vous ne pouvez donc pas les définir comme statiques car les méthodes statiques ne peuvent pas être abstraites.

Une interface ne peut jamais être déréférencée de manière statique, par exemple, ISomething.member . Une interface est toujours déréférencée via une variable qui fait référence à une instance d’une sous-classe de l’interface. Ainsi, une référence d’interface ne peut jamais savoir à quelle sous-classe elle fait référence sans une instance de sa sous-classe.

Ainsi, l’approximation la plus proche d’une méthode statique dans une interface serait une méthode non statique qui ignore “this”, c’est-à-dire qu’elle n’accède à aucun membre non statique de l’instance. À l’abstraction de bas niveau, toute méthode non statique (après recherche dans une vtable) n’est en réalité qu’une fonction avec une étendue de classe qui prend “this” comme paramètre formel implicite. Voir l’object singleton de Scala et l’interopérabilité avec Java comme preuve de ce concept. Et donc toute méthode statique est une fonction avec une étendue de classe qui ne prend pas de paramètre “this”. Ainsi, normalement, une méthode statique peut être appelée de manière statique, mais comme indiqué précédemment, une interface n’a pas d’implémentation (est abstraite).

Par conséquent, pour obtenir l’approximation la plus proche d’une méthode statique dans une interface, utilisez une méthode non statique, puis n’accédez à aucun membre d’instance non statique. Il n’y aurait aucun avantage de performance possible d’une autre manière, car il n’y a aucun moyen de lier statiquement (au moment de la compilation) un ISomething.member() . Le seul avantage que je vois d’une méthode statique dans une interface est qu’elle n’insère pas (c’est-à-dire ignore) une implication «this» et empêche donc l’access à n’importe lequel des membres d’instance non statiques. Cela déclarerait implicitement que la fonction qui n’accède pas à “this” est immutate et même pas en lecture seule par rapport à sa classe contenant. Mais une déclaration de “statique” dans une interface serait également une ISomething confusion pour les personnes qui tentaient d’y accéder avec ISomething.member() ce qui provoquerait une erreur de compilation. Je suppose que si l’erreur du compilateur était suffisamment explicative, il serait préférable d’essayer d’éduquer les gens sur l’utilisation d’une méthode non statique pour accomplir ce qu’ils veulent (apparemment principalement des méthodes d’usine), comme nous le faisons ici Des temps de questions sur ce site), il est donc évident que ce problème n’est pas intuitif pour de nombreuses personnes. Je devais y réfléchir pendant un moment pour avoir la bonne compréhension.

La façon d’obtenir un champ statique mutable dans une interface est d’utiliser des méthodes getter et setter non statiques dans une interface pour accéder à ce champ statique qui se trouve dans la sous-classe. Sidenote, statiques apparemment immuables peuvent être déclarés dans une interface Java avec static final .

Les interfaces fournissent juste une liste de choses qu’une classe fournira, pas une implémentation réelle de ces choses, qui est ce que votre élément statique est.

Si vous voulez des statistiques, utilisez une classe abstraite et héritez-en, sinon, supprimez le statique.

J’espère que cela pourra aider!

Vous ne pouvez pas définir de méthodes statiques dans une interface car les méthodes statiques appartiennent à une classe et non à une instance de classe, et les interfaces ne sont pas des classes. Lire plus ici.

Cependant, si vous voulez, vous pouvez le faire:

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

Dans ce cas, vous avez deux classes avec deux méthodes statiques distinctes appelées methodX ().

Supposons que vous puissiez le faire; considérez cet exemple:

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

Quelque chose qui pourrait être implémenté est l’interface statique (au lieu de la méthode statique dans une interface). Toutes les classes implémentant une interface statique donnée doivent implémenter les méthodes statiques correspondantes. Vous pouvez obtenir une interface statique SI à partir de n’importe quel classe clazz en utilisant

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

alors vous pouvez appeler si.method(params) . Cela serait utile (pour le modèle de conception d’usine par exemple) car vous pouvez obtenir (ou vérifier l’implémentation) de l’implémentation de méthodes statiques SI à partir d’une classe inconnue de compilation! Une répartition dynamic est nécessaire et vous pouvez remplacer les méthodes statiques (si elles ne sont pas définitives) d’une classe en l’étendant (lorsqu’elles sont appelées via l’interface statique). De toute évidence, ces méthodes ne peuvent accéder qu’aux variables statiques de leur classe.

Même si je me rends compte que Java 8 résout ce problème, je pensais que je pourrais émettre un scénario sur lequel je travaille actuellement (verrouillé par Java 7), où il serait utile de pouvoir spécifier des méthodes statiques dans une interface.

J’ai plusieurs définitions d’énumération où j’ai défini les champs “id” et “displayName” avec des méthodes d’aide évaluant les valeurs pour diverses raisons. L’implémentation d’une interface me permet de vérifier que les méthodes getter sont en place, mais pas les méthodes d’assistance statique. En tant qu’énumération, il n’y a pas vraiment de moyen propre de décharger les méthodes d’assistance dans une classe abstraite héritée ou quelque chose du genre, de sorte que les méthodes doivent être définies dans l’énumération elle-même. De plus, comme il s’agit d’une énumération, vous ne pourrez jamais le passer en tant qu’object instancié et le traiter comme le type d’interface, mais c’est ce qui me plait le plus il est supporté en Java 8.

Voici le code illustrant mon propos.

Définition de l’interface:

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

Exemple d’une définition enum:

 public enum ExecutionModeType implements IGenericEnum { STANDARD ("Standard", "Standard Mode"), DEBUG ("Debug", "Debug Mode"); Ssortingng id; Ssortingng displayName; //Getter methods public Ssortingng getId() { return id; } public Ssortingng getDisplayName() { return displayName; } //Constructor private ExecutionModeType(Ssortingng id, Ssortingng displayName) { this.id = id; this.displayName = displayName; } //Helper methods - not enforced by Interface public static boolean isValidId(Ssortingng id) { return GenericEnumUtility.isValidId(ExecutionModeType.class, id); } public static Ssortingng printIdOptions(Ssortingng delimiter){ return GenericEnumUtility.printIdOptions(ExecutionModeType.class, delimiter); } public static Ssortingng[] getIdArray(){ return GenericEnumUtility.getIdArray(ExecutionModeType.class); } public static ExecutionModeType getById(Ssortingng id) throws NoSuchObjectException { return GenericEnumUtility.getById(ExecutionModeType.class, id); } } 

Définition de l’utilitaire enum générique:

 public class GenericEnumUtility { public static  & IGenericEnum> boolean isValidId(Class enumType, Ssortingng id) { for(IGenericEnum enumOption : enumType.getEnumConstants()) { if(enumOption.getId().equals(id)) { return true; } } return false; } public static  & IGenericEnum> Ssortingng printIdOptions(Class enumType, Ssortingng delimiter){ Ssortingng ret = ""; delimiter = delimiter == null ? " " : delimiter; int i = 0; for(IGenericEnum enumOption : enumType.getEnumConstants()) { if(i == 0) { ret = enumOption.getId(); } else { ret += delimiter + enumOption.getId(); } i++; } return ret; } public static  & IGenericEnum> Ssortingng[] getIdArray(Class enumType){ List idValues = new ArrayList(); for(IGenericEnum enumOption : enumType.getEnumConstants()) { idValues.add(enumOption.getId()); } return idValues.toArray(new Ssortingng[idValues.size()]); } @SuppressWarnings("unchecked") public static  & IGenericEnum> T getById(Class enumType, Ssortingng id) throws NoSuchObjectException { id = id == null ? "" : id; for(IGenericEnum enumOption : enumType.getEnumConstants()) { if(id.equals(enumOption.getId())) { return (T)enumOption; } } throw new NoSuchObjectException(Ssortingng.format("ERROR: \"%s\" is not a valid ID. Valid IDs are: %s.", id, printIdOptions(enumType, " , "))); } } 

Supposons que les méthodes statiques soient autorisées dans les interfaces: * Elles forceraient toutes les classes d’implémentation à déclarer cette méthode. * Les interfaces seraient généralement utilisées à travers des objects, de sorte que les seules méthodes efficaces seraient celles qui ne sont pas statiques. * Toute classe connaissant une interface particulière peut invoquer ses méthodes statiques. Par conséquent, la méthode statique d’une classe d’implémentation serait appelée en dessous, mais la classe d’invocateur ne sait pas laquelle. Comment le savoir? Il n’a pas d’instanciation pour le deviner!

Les interfaces étaient censées être utilisées lors de l’utilisation d’objects. De cette façon, un object est instancié à partir d’une classe particulière, donc cette dernière question est résolue. La classe invoquante n’a pas besoin de savoir quelle classe particulière est parce que l’instanciation peut être effectuée par une troisième classe. La classe invoquante ne connaît donc que l’interface.

Si nous voulons que ceci soit étendu aux méthodes statiques, nous devrions avoir la possibilité de spécifier une classe d’implémentation avant de passer une référence à la classe invoquante. Cela pourrait utiliser la classe via les méthodes statiques de l’interface. Mais quelle est la différence entre cette référence et l’object? Nous avons juste besoin d’un object représentant ce que c’était la classe. Maintenant, l’object représente l’ancienne classe et pourrait implémenter une nouvelle interface, y compris les anciennes méthodes statiques – celles-ci sont désormais non statiques.

Les métaclasses servent à cette fin. Vous pouvez essayer la classe Class of Java. Mais le problème est que Java n’est pas assez flexible pour cela. Vous ne pouvez pas déclarer une méthode dans l’object de classe d’une interface.

Ceci est un problème de méta – quand vous devez faire du cul

..blah blah

de toute façon, vous avez une solution de contournement facile – rendant la méthode non statique avec la même logique. Mais alors vous devrez d’abord créer un object pour appeler la méthode.

Pour résoudre ce problème: error: corps de la méthode manquant, ou déclarer le principal vide statique abstrait (Ssortingng [] args);

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

sortie: 20

Maintenant, nous pouvons utiliser la méthode statique dans l’interface

Je pense que java n’a pas de méthode d’interface statique car vous n’en avez pas besoin. Vous pensez peut-être que vous faites, mais … Comment les utiliseriez-vous? Si vous voulez les appeler comme

 MyImplClass.myMethod() 

alors vous n’avez pas besoin de le déclarer dans l’interface. Si vous voulez les appeler comme

 myInstance.myMethod() 

alors il ne devrait pas être statique. If you are actually going to use first way, but just want to enforce each implementation to have such static method, then it is really a coding convention, not a contract between instance that implements an interface and calling code.

Interfaces allow you to define contract between instance of class that implement the interface and calling code. And java helps you to be sure that this contract is not violated, so you can rely on it and don’t worry what class implements this contract, just “someone who signed a contract” is enough. In case of static interfaces your code

 MyImplClass.myMethod() 

does not rely on the fact that each interface implementation has this method, so you do not need java to help you to be sure with it.

What is the need of static method in interface, static methods are used basically when you don’t have to create an instance of object whole idea of interface is to bring in OOP concepts with introduction of static method you’re diverting from concept.