Java - Pourquoi tous les champs d'une interface sont-ils implicitement statiques et finaux?

Question

J'essaie simplement de comprendre pourquoi tous les champs définis dans une interface sont implicitement static et final . L'idée de conserver les champs static me semble logique, car vous ne pouvez pas avoir d'objets d'interface mais pourquoi ils sont final (implicitement)?

Tout le monde sait pourquoi les concepteurs Java ont créé les champs dans une interface static et final ?

Answer 1

Une interface ne peut pas avoir un comportement ou un état car elle est destinée à spécifier uniquement un contrat d'interaction, pas de détails d'implémentation. Aucun comportement n'est imposé en n'autorisant pas les corps de méthode / constructeur ni les blocs d'initialisation static / instance. Aucun état n'est imposé en n'autorisant que les constantes. Une constante en Java est définie par un champ final statique (et par convention, le nom utilise UPPER_CASE_AND_UNDERSCORES).

Answer 2

RAISON D'ÊTRE FINAL--

Toute implémentation peut changer la valeur des champs si elles ne sont pas définies en tant que final. Ensuite, ils deviendraient une partie de la mise en œuvre. Une interface est une spécification pure sans aucune implémentation.

RAISON D'ÊTRE STATIQUE--

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

Answer 3

Il ya un couple de points passés sous silence par ici:

Tout simplement parce que les champs dans une interface sont implicitement static final ne signifie pas qu'ils doivent être des constantes de compilation, ou encore immuable. Vous pouvez définir par exemple

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

(Attention que cela à l'intérieur d'une annotation définition peut confondre javac, concernant le fait que le ci-dessus compile en fait à un initialiseur statique.)

Aussi, la raison de cette restriction est plus stylistique que technique, et beaucoup de gens seraient afin d'être détendu.

Answer 4

Les champs doivent être statiques car ils ne peuvent pas être abstraits (comme les méthodes peuvent). 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.

Je pense que les champs doivent être définitifs, car ils peuvent être consultés par de nombreux implémenteurs différents, ce qui peut être problématique (comme la synchronisation). Aussi pour éviter qu'il soit re-implémenté (caché).

Juste ma pensée.

Answer 5

Je considère que l'exigence que les champs définitif trop restrictive et une erreur de saisie par le langage Java les concepteurs. Il y a des moments, par exemple, l'arbre de la manipulation, quand vous en avez besoin pour définir des constantes dans la mise en œuvre qui sont nécessaires pour effectuer des opérations sur un objet du type d'interface. La sélection d'un chemin de code sur la mise en œuvre de la classe est une bidouille. La solution que j'utilise est de définir une fonction d'interface et de mettre en œuvre, en retour d'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 claire et moins sujettes à la aberrante de mise en œuvre pour 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";
    ...
}