Pourquoi tous les champs d'une interface sont-ils implicitement statiques et définitifs?

J'essaie juste de comprendre pourquoi tous les champs définis dans une interface sont implicitement staticet final. L'idée de garder des champs a du staticsens pour moi car vous ne pouvez pas avoir d'objets d'une interface mais pourquoi ils le sont final(implicitement)?

Tout le monde sait pourquoi les concepteurs Java ont choisi de créer les champs dans une interface staticet final?

Une interface ne peut pas avoir de comportement ou d'état car elle est destinée à spécifier uniquement un contrat d'interaction, pas de détails d'implémentation. 'Aucun comportement' est appliqué en n'autorisant pas les corps de méthode / constructeur ou les blocs d'initialisation statiques / d'instance. «Aucun état» est appliqué en autorisant uniquement les champs finaux statiques. Par conséquent, la classe peut avoir un état (état statique), mais l'état de l'instance n'est pas déduit par l'interface.

BTW: Une constante en Java est définie par un champ final statique (et par convention le nom utilise UPPER_CASE_AND_UNDERSCORES).

Raison d'être final

Toutes les implémentations peuvent changer la valeur des champs si elles ne sont pas définies comme définitives. Ensuite, ils feraient partie de la mise en œuvre. Une interface est une spécification pure sans aucune implémentation.

Raison d'être static

S'ils sont statiques, ils appartiennent à l'interface, et non à l'objet, ni au type d'exécution de l'objet.

Il y a quelques points passés sous silence ici:

Ce n'est pas parce que les champs d'une interface sont implicitement statiques finaux qu'ils doivent être des constantes à la compilation, ou même immuables. Vous pouvez définir par exemple

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Méfiez-vous que faire cela dans une définition d'annotation peut confondre javac , lié au fait que ce qui précède se compile réellement en un initialiseur statique.)

De plus, la raison de cette restriction est plus stylistique que technique, et beaucoup de gens aimeraient qu'elle soit détendue .

Les champs doivent être statiques car ils ne peuvent pas être abstraits (comme le peuvent les méthodes). Parce qu'ils ne peuvent pas être abstraits, les implémenteurs ne seront pas en mesure de fournir logiquement les différentes implémentations des champs.

Les champs doivent être définitifs, je pense, car les champs peuvent être accédés par de nombreux implémenteurs différents, ce qui leur permet d'être modifiables peut être problématique (comme la synchronisation). Aussi pour éviter qu'il soit réimplémenté (caché).

Juste ma pensée.

Je considère que l'exigence que les champs soient définitifs est indûment restrictive et constitue une erreur des concepteurs du langage Java. Il y a des moments, par exemple la gestion d'arborescence, où vous devez définir des constantes dans l'implémentation qui sont nécessaires pour effectuer des opérations sur un objet de type interface. La sélection d'un chemin de code sur la classe d'implémentation est un kludge. La solution de contournement que j'utilise est de définir une fonction d'interface et de l'implémenter en renvoyant un littéral:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Cependant, il serait plus simple, plus clair et moins sujet à une implémentation aberrante d'utiliser cette syntaxe:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Spécification, contrats ... L'instruction machine pour l'accès au champ utilise l'adresse de l'objet plus le décalage du champ. Comme les classes peuvent implémenter de nombreuses interfaces, il n'y a aucun moyen de faire en sorte que le champ d'interface non final ait le même décalage dans toutes les classes qui étendent cette interface. Par conséquent, un mécanisme différent pour l'accès au champ doit être implémenté: deux accès mémoire (obtenir le décalage du champ, obtenir la valeur du champ) au lieu d'un plus le type de table de champ virtuel (analogue de la table de méthode virtuelle). Je suppose qu'ils ne voulaient tout simplement pas compliquer jvm pour des fonctionnalités qui peuvent être facilement simulées via des éléments existants (méthodes).

Dans scala, nous pouvons avoir des champs dans les interfaces, bien qu'ils soient implémentés en interne comme je l'ai expliqué ci-dessus (en tant que méthodes).

static:

Tout ce qui est staticen Java (variable ou méthode) peut être appelé en tant que Classname.variablenameou Classname.methodnameou directement. Il n'est pas obligatoire de l'invoquer uniquement en utilisant le nom de l'objet.

Dans l'interface, les objets ne peuvent pas être déclarés et staticpermettent d'appeler des variables uniquement via le nom de classe sans avoir besoin du nom d'objet.

final:

Cela aide à maintenir une valeur constante pour une variable car elle ne peut pas être remplacée dans ses sous-classes.