Les méthodes d’une interface Java doivent-elles être déclarées avec ou sans modificateur d’access public?

Les méthodes d’une interface Java doivent-elles être déclarées avec ou sans le modificateur d’access public ?

Techniquement, cela n’a pas d’importance, bien sûr. Une méthode de classe qui implémente une interface est toujours public . Mais qu’est-ce qu’une meilleure convention?

Java lui-même n’est pas cohérent à cet égard. Voir par exemple Collection vs. Comparable , ou Future vs. ScriptEngine .

Le JLS le dit clairement:

Il est permis, mais déconseillé par style, de spécifier de manière redondante le modificateur public et / ou abstract pour une méthode déclarée dans une interface.

Le modificateur public devrait être omis dans les interfaces Java (à mon avis).

Comme il n’ajoute aucune information supplémentaire, cela détourne l’attention des choses importantes.

La plupart des guides de style vous recommanderont de ne pas utiliser de guide, mais le plus important est de restr cohérent dans votre base de code, et en particulier pour chaque interface. L’exemple suivant pourrait facilement dérouter quelqu’un qui ne parle pas 100% couramment Java:

 public interface Foo{ public void MakeFoo(); void PerformBar(); } 

Malgré le fait que cette question a été posée il y a longtemps mais je pense qu’une description complète clarifierait pourquoi il n’est pas nécessaire d’utiliser des méthodes abstraites publiques avant les méthodes statiques publiques avant les constantes d’une interface.

Tout d’abord, les interfaces sont utilisées pour spécifier des méthodes communes pour un ensemble de classes non liées pour lesquelles chaque classe aura une implémentation unique. Par conséquent, il n’est pas possible de spécifier le modificateur d’access comme privé, car les autres classes ne peuvent pas le modifier.

Deuxièmement, bien que l’on puisse initier des objects d’un type d’interface, une interface est réalisée par les classes qui l’implémentent et non héritée. Et comme une interface peut être implémentée (réalisée) par différentes classes non liées qui ne sont pas dans le même package, le modificateur d’access protégé n’est pas non plus valide. Donc, pour le modificateur d’access, nous n’avons plus que le choix du public.

Troisièmement, une interface n’a aucune implémentation de données, y compris les variables et méthodes d’instance. S’il existe une raison logique d’insérer des méthodes implémentées ou des variables d’instance dans une interface, il doit s’agir d’une super-classe dans une hiérarchie d’inheritance et non d’une interface. Compte tenu de ce fait, aucune méthode ne pouvant être implémentée dans une interface, toutes les méthodes de l’interface doivent donc être abstraites.

Quasortingèmement, Interface ne peut inclure de constantes que ses membres de données, ce qui signifie qu’elles doivent être définitives et que, bien sûr, les constantes finales sont déclarées statiques pour en conserver une seule. Par conséquent, statique final est également un must pour les constantes d’interface.

Donc, en conclusion, bien que l’utilisation de abstract public avant les méthodes et de statiques statiques avant les constantes d’une interface soit valide, mais qu’il n’y a pas d’autres options, elle est considérée comme redondante et non utilisée.

Je voudrais éviter de mettre des modificateurs qui sont appliqués par défaut. Comme cela a été souligné, cela peut entraîner une incohérence et une confusion.

Le pire que j’ai vu est une interface avec des méthodes déclarées abstract

J’ai utilisé des méthodes de déclaration avec le modificateur public , car cela rend le code plus lisible, surtout avec la coloration syntaxique. Cependant, dans notre dernier projet, nous avons utilisé Checkstyle, qui affiche un avertissement avec la configuration par défaut pour public modificateurs public sur les méthodes d’interface.

Donc, je ne suis pas sûr de ce qui est le mieux, mais une chose que je n’aime pas vraiment, c’est d’utiliser public abstract sur les méthodes d’interface. Eclipse le fait parfois lors de la refactorisation avec “Extract Interface”.

J’écris toujours ce que j’utiliserais s’il n’y avait pas d’interface et j’écrivais une implémentation directe, c’est-à-dire que j’utiliserais public .

La raison pour laquelle les méthodes dans les interfaces sont par défaut publiques et abstraites semble tout à fait logique et évidente pour moi.

Une méthode dans une interface est par défaut abstraite pour forcer la classe d’implémentation à fournir une implémentation et elle est publique par défaut pour que la classe d’implémentation ait le droit de le faire.

L’ajout de ces modificateurs dans votre code est redondant et inutile et ne peut que conduire à la conclusion que vous ne connaissez pas et / ou que vous ne comprenez pas les principes fondamentaux de Java.

Je préfère le sauter, j’ai lu quelque part que les interfaces sont par défaut, public et abstract .

A ma grande surprise, le livre – Head First Design Patterns , utilise public avec des déclarations d’interface et des méthodes d’interface … qui m’ont fait repenser une fois de plus et j’ai atterri sur ce post.

Quoi qu’il en soit, je pense que les informations redondantes doivent être ignorées.

Avec l’introduction de modificateurs private , static , default pour les méthodes d’interface en Java 8/9, les choses se compliquent et j’ai tendance à penser que les déclarations complètes sont plus lisibles (nécessite la compilation de Java 9):

 public interface MyInterface { //minimal int CONST00 = 0; void method00(); static void method01() {} default void method02() {} private static void method03() {} private void method04() {} //full public static final int CONST10 = 0; public abstract void method10(); public static void method11() {} public default void method12() {} private static void method13() {} private void method14() {} } 

C’est totalement subjectif. Je omet le modificateur public redondant car il semble être encombré. Comme mentionné par d’autres – la cohérence est la clé de cette décision.

Il est intéressant de noter que les concepteurs de langage C # ont décidé d’appliquer cela. Déclarer une méthode d’interface comme publique dans C # est en fait une erreur de compilation. La cohérence n’est probablement pas importante dans toutes les langues, donc je suppose que cela ne concerne pas directement Java.

Les gens apprendront votre interface en complétant le code dans leur IDE ou dans Javadoc, et non en lisant la source. Il est donc inutile de mettre “public” dans la source – personne ne lit la source.