Interface abstraite Java

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?

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

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.

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.

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)

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.

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

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

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.

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