Protégé dans les interfaces

Pourquoi toutes les méthodes sont-elles interfaceimplicitement dans une définition public? Pourquoi n'autorise-t-il pas une protectedméthode?

Parce qu'une interface est censée signifier "ce que vous pouvez voir de l'extérieur de la classe". Il ne serait pas logique d'ajouter des méthodes non publiques.

Bien que la raison souvent citée soit que "les interfaces définissent les API publiques", je pense que c'est une simplification excessive. (Et ça «sent» aussi la logique circulaire.)

Il ne serait pas inutile d'avoir des interfaces qui ont un mélange de modificateurs d'accès; par exemple en partie public et en partie restreint à d'autres classes dans le même package que l'interface. En fait, dans certains cas, cela pourrait être utile en bas à droite, OMI.

En fait, je pense que le raisonnement derrière la publication implicite des membres d'une interface est que cela simplifie le langage Java :

• Les membres de l'interface implicitement publics sont plus simples à gérer pour les programmeurs. Combien de fois avez-vous vu du code (classes) où les modificateurs d'accès aux méthodes ont été choisis apparemment au hasard? De nombreux programmeurs «ordinaires» ont du mal à comprendre comment gérer au mieux les limites d'abstraction Java ¹ . L'ajout de public / protected / package-private aux interfaces rend la tâche encore plus difficile pour elles.

• Implicitement, les membres de l'interface publique simplifient la spécification du langage ... et donc la tâche des rédacteurs du compilateur Java et des personnes qui implémentent les API Reflection.

La ligne de pensée selon laquelle les "interfaces définissent les API publiques" est sans doute une conséquence (ou caractéristique) de la décision de simplification de la conception du langage ... et non l'inverse. Mais en réalité, les deux lignes de pensée se sont probablement développées en parallèle dans l'esprit des concepteurs de Java.

Quoi qu'il en soit, la réponse officielle à la RFE dans JDK-8179193 indique clairement que l'équipe de conception Java a décidé ² que permettreprotected les interfaces ajoute de la complexité pour peu d'avantages réels. Félicitations à @skomisa pour avoir trouvé les preuves .

Les preuves contenues dans la RFE règlent la question. C'est la raison officielle pour laquelle cela n'a pas été ajouté.

^{1 - Bien sûr, les programmeurs de haut niveau n'ont aucune difficulté avec ces choses, et peuvent accueillir une palette plus riche de fonctionnalités de contrôle d'accès. Mais que se passe-t-il lorsque leur code est remis à quelqu'un d'autre pour qu'il le maintienne?}

^{2 - Vous pouvez être en désaccord avec leur décision ou leur raisonnement, mais c'est sans objet.}

Je dois dire que cette question a été rouverte par l'introduction de méthodes par défaut dans Java 8. Le projet sur lequel je travaille actuellement est, similaire à la nature de base d'une interface, destiné à abstraction de l'intention de l'implémentation.

Il y a plusieurs cas dans lesquels je pourrais considérablement simplifier mon code avec une méthode "protégée par défaut". Il s'avère que cela ne fonctionne pas réellement, car les interfaces restent fidèles à la logique Java 7. Une méthode protégée normale n'a aucun sens, pour les raisons mentionnées ci-dessus; mais si une méthode publique par défaut nécessite une ressource de bas niveau qui ne changera probablement pas et peut être fournie par une méthode protégée, il me semble qu'avoir un travail "protégé par défaut" ne maintiendrait pas seulement un code plus propre, cela protégerait les futurs utilisateurs de abus accidentels.

(Cela ne change pas tragiquement le fait que je dois encore trop compliquer mon code avec des résumés autrement inutiles; mais j'ai l'intention de mettre une demande de fonctionnalité chez Oracle.)

Parce que les interfaces définissent les API publiques. Tout ce qui est protégé est un détail interne qui n'appartient pas à une interface.

Vous pouvez utiliser des classes abstraites avec des méthodes abstraites protégées, mais les interfaces sont limitées aux méthodes publiques et aux champs finaux statiques publics.

Peut-être parce que c'est une interface , c'est-à-dire qu'il est là pour dire aux clients ce qu'ils peuvent faire avec des instances, plutôt que pour leur dire ce qu'ils ne peuvent pas faire.

Je pense fermement que les interfaces devraient permettre des méthodes protégées; Qui a dit que les interfaces doivent être visibles de tous dans le monde entier? Quant à votre argument selon lequel cela pourrait confondre les programmeurs "ordinaires" (lire: incompétents): Une grande partie de la POO concerne la structuration correcte des objets, des classes, des packages, etc., si un programmeur a du mal à faire tout cela correctement, il a un problème beaucoup plus important. Java a été conçu pour ce type de chose.

Plusieurs réponses ici utilisent un raisonnement circulaire pour expliquer pourquoi les méthodes d'interface ne peuvent pas être protégées: c'est parce qu'elles doivent être publiques, donc évidemment elles ne peuvent pas être protégées!

Cela n'explique rien, mais heureusement, quelqu'un a soulevé une demande d'amélioration des méthodes protégées dans les interfaces en tant que bogue JDK il y a quelques années, ce qui éclaire un peu le problème:

Méthodes protégées dans les interfaces: partager entre les packages

Étant donné que les modificateurs sont un peu limités en Java, un moyen de partager des méthodes entre des packages est limité aux méthodes publiques. Parfois, il est dangereux de rendre une méthode publique, mais cela doit être dû au manque de modificateurs appropriés. Ma solution surmonte cette limitation.

La spécification du langage Java n'autorise actuellement pas le modificateur protected pour les méthodes d'interface. Nous pouvons profiter de ce fait et utiliser des méthodes d'interface protégées pour cette nouvelle fonctionnalité.

Si une méthode d'interface est marquée comme protégée et que l'interface est implémentée par une classe dans un autre package, la méthode n'aurait pas besoin d'être publique, mais pourrait également être privée ou au moins protégée par un package. La méthode est visible, ce que la classe déclare être et en plus visible dans le paquet source de l'interface (et les sous-packages?).

De cette façon, nous pourrions partager certaines méthodes dans des packages bien connus.

Et voici la réponse à cette demande d'amélioration, qui a été clôturée avec le statut Won't fix:

Cette proposition tente de résoudre un problème d'une manière qui ajoute de la complexité et des cas spéciaux pour peu de gain réel. Une manière typique de résoudre ce problème est d'avoir une classe privée qui implémente une interface publique. Les méthodes d'implémentation sont publiques, mais se trouvent dans une classe privée, elles restent donc privées.

Une alternative disponible à partir de Java 9 est de rendre les classes et les méthodes publiques, mais dans un module qui a une exportation qualifiée vers des modules "amis" spécifiques au lieu d'être exportés vers le grand public.

Les points à retenir de ce rapport de bogue sont donc:

• La situation actuelle ne va pas changer; Il est peu probable que les interfaces prennent en charge les protectedméthodes.
• La justification de ne pas prendre en charge les protectedméthodes dans les interfaces est que cela « ajoute de la complexité et des cas spéciaux pour un gain réel minime ».
• Depuis Java 9, il existe une approche alternative pour fournir un accès au niveau du package aux méthodes. Utilisez le Java Platform Module System (JPMS) pour " rendre les classes et les méthodes publiques, mais dans un module qui a une exportation qualifiée vers des modules" amis "spécifiques au lieu d'être exportés vers le grand public ".

Puisqu'une classe d'implémentation doit implémenter TOUTES les méthodes déclarées dans votre interface, que se passerait-il si votre classe d'implémentation était dans un package différent?

Interface Si vous voulez utiliser quelque chose comme vous l'avez décrit, continuez avec des classes abstraites ou des interfaces imbriquées.

Un extrait du style de code sur les variables d'interface, mais qui s'applique toujours aux méthodes:

Les variables d'interface sont implicitement publiques car les interfaces sont destinées à fournir une interface de programmation d'application (API) entièrement accessible aux programmeurs Java pour la référence et l'implémentation dans leurs propres applications. Puisqu'une interface peut être utilisée dans des packages Java différents des leurs, la visibilité publique garantit que le code du programme peut accéder à la variable.

Déclarer des sous- protectedinterfaces internes est une bonne pratique, mais vous ne pouvez pas déclarer vos méthodes internes comme dans une interface en Java, techniquement.

Bien sûr, vous pouvez créer une autre interface à usage interne qui étend l'interface publique:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

Vous pouvez utiliser l' InternalInterfaceinterface à l'intérieur du package, mais vous devez accepter tout sous-type de PublicInterface(dans les méthodes publiques):

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

En dehors du package, les utilisateurs peuvent utiliser PublicInterfacesans problème.

Les programmeurs créent généralement des classes abstraites dans des situations similaires. Cependant, dans ce cas, nous perdons les avantages de l'héritage multiple.

Le seul scénario où cela aurait du sens est celui où vous souhaitez restreindre la visibilité au même package. Toutes les autres utilisations de protectedne sont pas applicables. Plus précisément, les protectedméthodes sont souvent utilisées pour donner accès à certains détails des implémentations de niveau inférieur pour les descendants. Mais déclarer cela dans une interface n'a pas de sens, car il n'y a pas d'implémentation de niveau inférieur à exposer.

Et même le scénario de package n'est pas vraiment ce que sont les interfaces.

Pour réaliser ce que vous souhaitez probablement, vous avez besoin de deux interfaces, une à usage interne et une que vous exposez dans l'API publique. (Avec l'interne peut-être, mais pas nécessairement étendre le public.) Ou, comme d'autres l'ont souligné, une superclasse abstraite.

Les méthodes protégées sont toujours accessibles par sous-classe uniquement si la sous-classe étend la classe de base.

En cas d'interface, la sous-classe n'étend jamais l'interface. Il implémente l'interface.

Les méthodes protégées sont accessibles via extend et non avec un outil .

Les interfaces sont destinées à exposer les méthodes au monde extérieur . Ainsi, ces méthodes sont publiques par nature. Cependant, si vous voulez introduire l' abstraction dans la même famille de classes, c'est possible en créant un autre niveau d'abstraction entre votre interface et la classe d'implémentation, c'est-à-dire une classe abstraite. Un exemple est présenté ci-dessous.

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}