Interface abstraite Java


197

Prenons un exemple (qui se compile en java)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

Pourquoi est-il nécessaire qu'une interface soit "déclarée" abstraite? Y a-t-il d'autres règles qui s'appliquent à une interface abstraite?


Enfin: si abstractest obsolète, pourquoi est-il inclus dans Java? Y a-t-il une histoire pour l'interface abstraite?



5
Pas un double compte tenu de la partie " Enfin: .... ".
aioobe

Cette question connexe cite un exemple réel: stackoverflow.com/questions/4380796/…
Raedwald

1
Et pourquoi Eclipse ajoute-t-il «abstrait» par défaut lorsque vous «extrayez l'interface»?
ModdyFire

@ModdyFire, veuillez élaborer?
Buhake Sindi

Réponses:


447

Pourquoi est-il nécessaire qu'une interface soit "déclarée" abstraite?

Ce n'est pas.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

Les interfaces et leurs méthodes sont implicites abstractet l'ajout de ce modificateur ne fait aucune différence.

Y a-t-il d'autres règles qui s'appliquent à une interface abstraite?

Non, les mêmes règles s'appliquent. La méthode doit être implémentée par n'importe quelle classe d'implémentation (concrète).

Si le résumé est obsolète, pourquoi est-il inclus dans Java? Y a-t-il une histoire pour l'interface abstraite?

Question interessante. J'ai déterré la première édition de JLS, et même là, il est dit "Ce modificateur est obsolète et ne devrait pas être utilisé dans les nouveaux programmes Java" .

D'accord, creuser encore plus loin ... Après avoir heurté de nombreux liens cassés, j'ai réussi à trouver une copie de la spécification Oak 0.2 originale (ou "manuel"). Une lecture assez intéressante je dois dire, et seulement 38 pages au total! :-)

Sous la section 5, Interfaces, il fournit l'exemple suivant:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

Et en marge ça dit

À l'avenir, la partie "= 0" de la déclaration des méthodes dans les interfaces pourrait disparaître.

En supposant que =0le abstractmot - clé ait été remplacé , je soupçonne que abstractc'était à un moment donné obligatoire pour les méthodes d'interface!


Article connexe: Java: interfaces abstraites et méthodes d'interface abstraite


3
mais l'abstrait lui-même n'est pas obsolète, ou? Il est obsolète pour les interfaces mais il existe encore des classes et des méthodes abstraites.
user85421

Merci ;-) Je pense que j'ai finalement cloué l'origine pour avoir même autorisé les abstractméthodes d'interface.
aioobe

13
Sensationnel. Il est donc obsolète "par conception". Ces concepteurs JLS avaient vraiment toujours peur de casser quelque chose, même de casser des choses qui ne sont jamais sorties ... :-)
Lukas Eder

@aioobe, vous devez être le robot d'exploration de Google que nous ne connaissons pas ... lol
Buhake Sindi

18
Btw. "public" n'est pas non plus nécessaire sur les méthodes dans une déclaration d'interface ... elles sont toujours publiques.
rec

37

Ce n'est pas nécessaire, c'est facultatif, tout comme publicpour les méthodes d'interface.

Voir le JLS à ce sujet:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 Interfaces abstraites Chaque interface est implicitement abstraite. Ce modificateur est obsolète et ne doit pas être utilisé dans les nouveaux programmes.

Et

9.4 Déclarations de méthode abstraite

[...]

Pour des raisons de compatibilité avec les anciennes versions de la plate-forme Java, il est autorisé, mais découragé, de spécifier de manière redondante le modificateur abstrait pour les méthodes déclarées dans les interfaces.

Il est autorisé, mais fortement déconseillé pour des raisons de style, de spécifier de manière redondante le modificateur public pour les méthodes d'interface.


7
à JLS: Il est permis, mais fortement découragé, pour des raisons de style, d'écrire de manière redondante deux phrases avec la même signification et une formulation presque exacte l'une à côté de l'autre ...
n611x007

11

Il n'est pas nécessaire de déclarer l'interface abstraite.

Tout comme déclarer toutes ces méthodes publiques (qu'elles sont déjà si l'interface est publique) ou abstraites (qu'elles sont déjà dans une interface) est redondante.

Mais personne ne vous arrête.

Autres choses que vous pouvez déclarer explicitement, mais pas besoin de:

  • appeler super () sur la première ligne d'un constructeur
  • extends Object
  • implémenter des interfaces héritées

Y a-t-il d'autres règles qui s'appliquent à une interface abstraite?

Une interface est déjà "abstraite". Appliquer à nouveau ce mot-clé ne fait absolument aucune différence.


2
Apparemment, les méthodes sont même publiques si l'interface elle-même est privée de package.
Thilo

7

Sachez qu'au printemps, cela n'a pas de sens académique. L'interface abstraite est un avertissement au développeur de ne pas l'utiliser pour @Autowired. J'espère que spring / eclipse @Autowiredse penchera sur cet attribut et avertira / échouera sur ses utilisations.

Un exemple réel: @Service proxy sous @Transnational à un @Repository doit utiliser les mêmes méthodes de base, mais ils doivent utiliser des interfaces différentes qui étendent cette interface abstraite en raison de @Autowired. (J'appelle cette interface XXXSpec)


+1 bon coup, j'ai cherché largement une séparation des injections non passivables de sessionbean. Peut-être que je peux utiliser findbugs / checkstyle pour une règle ....
Grim

3

Chaque interface est implicitement abstraite.
Ce modificateur est obsolète et ne doit pas être utilisé dans les nouveaux programmes.

[Spécification du langage Java - 9.1.1.1 abstractInterfaces]

Notez également que les méthodes membres de l'interface le sont implicitement public abstract.
[Spécification du langage Java - Membres de l'interface 9.2]

Pourquoi ces modificateurs sont-ils implicites? Il n'y a pas d'autre modificateur (pas même le modificateur « pas de modificateur ») qui serait utile ici, vous n'avez donc pas à le saisir explicitement.


2

Ce n'est pas nécessaire. C'est une bizarrerie de la langue.


2

Ce n'est pas nécessaire, car les interfaces sont par défaut abstraites, car toutes les méthodes d'une interface sont abstraites.


-2

Une interface abstraite n'est pas aussi redondante que tout le monde semble le dire, du moins en théorie.

Une interface peut être étendue, tout comme une classe. Si vous concevez une hiérarchie d'interface pour votre application, vous pouvez très bien avoir une interface «de base», vous étendez d'autres interfaces à partir de mais ne voulez pas en tant qu'objet en soi.

Exemple:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

Vous ne voulez pas qu'une classe implémente MyBaseInterface, seulement les deux autres, MMyDog et MyBoat, mais les deux interfaces partagent l'interface MyBaseInterface, ont donc une propriété 'name'.

Je sais que c'est un peu académique, mais j'ai pensé que certains pourraient le trouver intéressant. :-)

C'est vraiment juste un «marqueur» dans ce cas, pour signaler aux implémenteurs de l'interface qu'il n'a pas été conçu pour être implémenté seul. Je dois souligner qu'un compilateur (au moins le sun / ora 1.6 avec lequel je l'ai essayé) compile une classe qui implémente une interface abstraite.


3
Je pense que vous avez absolument mal compris ma question.
Buhake Sindi

3
Je ne suis pas d'accord avec ce raisonnement. Je pense que chaque interface doit fournir un ensemble de fonctionnalités entièrement utilisable et que chaque interface peut donc être implémentée seule. De plus, il n'y aurait aucune raison pour qu'un compilateur refuse de compiler une classe implémentant une interface déclarée explicitement comme abstraite, car toutes les interfaces sont déjà implicitement abstraites. Cela changerait complètement la signification du mot-clé "abstrait".
BladeCoder

-3

Eh bien, «Abstract Interface» est une construction lexicale: http://en.wikipedia.org/wiki/Lexical_analysis .

Il est requis par le compilateur, vous pouvez également écrire interface.

Eh bien, n'entrez pas trop dans la construction lexicale du langage car ils pourraient l'avoir mis là pour résoudre une ambiguïté de compilation qui est qualifiée de cas spéciaux pendant le processus de compilation ou pour une certaine compatibilité descendante, essayez de vous concentrer sur la construction lexicale de base.

L'essence de `interface est de capturer un concept abstrait (idée / pensée / pensée d'ordre supérieur, etc.) dont la mise en œuvre peut varier ... c'est-à-dire qu'il peut y avoir plusieurs mises en œuvre.

Une interface est un type de données purement abstrait qui représente les caractéristiques de l'objet qu'elle capture ou représente.

Les entités peuvent être représentées par l'espace ou par le temps. Lorsqu'elles sont représentées par l'espace (stockage en mémoire), cela signifie que votre classe concrète implémentera un champ et des méthodes / méthodes qui fonctionneront sur ce champ ou en fonction du temps, ce qui signifie que la tâche d'implémentation de la fonctionnalité est purement computationnelle (nécessite plus d'horloges cpu pour le traitement) afin que vous ayez un compromis entre l'espace et le temps pour la mise en œuvre des fonctionnalités.

Si votre classe concrète n'implémente pas toutes les fonctionnalités, elle redevient abstraite parce que vous avez une implémentation de votre pensée ou idée ou de l'abstraction mais qu'elle n'est pas complète, vous la spécifiez par abstractclasse.

Une classe concrète sera une classe / un ensemble de classes qui capturera pleinement l'abstraction que vous essayez de capturer la classe XYZ.

Le motif est donc

Interface--->Abstract class/Abstract classes(depends)-->Concrete class

1
Cette réponse ne répond pas du tout à ma question. Aussi "It seams like you are new to Java. Vraiment?
Buhake Sindi

"l'abstrait est obsolète"
Manish

(1) "l'abstrait est obsolète" -> s'il le supprime et que le compilateur arrête de le reconnaître, alors la version précédente du code source utilisant "l'interface abstraite" ne compilera pas dans une version plus récente. Ils doivent maintenir la compatibilité descendante. Lorsque vous définissez une interface abstraite, le sens du mot-clé interface est coincé avec celui-ci "abstrait", qui est une version beaucoup plus propre, mais pour les programmeurs expérimentés comme vous, ils ont fourni le raccourci "interface" .. votre question est similaire à i = i + 1 == > i ++ .. vous avez le choix: D
Manish

Regardez la réponse acceptée. Je sais abstractest obsolète dans l'interface. Je voulais savoir pourquoi est-ce toujours acceptable et quelle est l'histoire derrière l' abstractinterface. Vous me donnez un guide Java 101 sur l'abstrait vs l'interface.
Buhake Sindi

Ce n'est pas une construction lexicale. C'est la syntaxe. Sémantiquement, c'est redondant. Il n'est pas «requis par le compilateur». La partie sur l'espace / temps est juste radotante. Aucune de ces absurdités ne répond à la question qui a été posée. N'utilisez pas la mise en forme de code pour du texte qui n'est pas du code.
Marquis de Lorne
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.