Java pourquoi interface étend de l'interface
Je me demande dans quelles circonstances ne nous étendre une interface à partir d'une interface? Parce que, par exemple
interface A{
public void method1();
}
interface B extends A{
public void method2();
}
class C implements B{
@Override public void method1(){}
@Override public void method2(){}
}
N'est-il pas équivalent à
interface A{
public void method1();
}
interface B{
public void method2();
}
class C implements A, B{
@Override public void method1(){}
@Override public void method2(){}
}
Existe-il des raisons importantes derrière ?
- Dans le premier cas, le programmeur de la classe C n'a pas besoin de connaître le détail que B hérite de A, il a juste besoin de lire la documentation pour B.
Vous devez vous connecter pour publier un commentaire.
Raisons importantes dépendent entièrement de ce que l'interface est censé faire.
Si vous disposez d'une interface de Véhicule et une interface en état de Rouler, il va de soi que tous les véhicules sont en état de rouler. Sans l'héritage de l'interface tous les types de voiture de classe va nécessiter
et ainsi de suite.
Comme je l'ai dit, tous les véhicules sont en état de rouler donc il est plus facile d'avoir de l':
Avec le Véhicule comme suit:
Et ne pas avoir à y penser.
Oui, il y a: c'est comme si l'héritage n'importe où ailleurs. Si B est un spécialisation d'Un alors qu'il devrait être écrit de cette façon. La seconde indique que la classe arrive juste à mettre en œuvre 2 interfaces avec pas de relation entre eux.
Du résultat final point de vue, vous pouvez simplement utiliser plusieurs interfaces en place d'une hiérarchie (tout comme vous pourriez éviter d'utiliser hérité de comportement dans une hiérarchie de classe). Cela laisserait des informations plus dispersés, cependant, et aussi (si pas plus) de manière significative, il dissimule l'intention de le modèle de logiciel.
interfaces
s'. Alors, Que signifie-t-il quand vous ditesB
estA
.interface
est découvert après les classes de béton sont conçus. Je sens l'extension des interfaces sort de la conséquence de la mauvaise conception. Si vous comprenez le sens deinherit
il ne fait pas de sens d'hériter d'une interface. Il un sens à hériter de la classe de béton, car ils représentent, ou de montrer la nature du monde réel des objets et vous héritez de la nature parce queSubType
est également partie de cette nature. BTW, Pouvez-vous me donner un exemple dans le jdk sur l'extension des interfaces? je tiens à les analyser.public interface List extends Collection{}
voulez-vous dire,List
estIterable
, Parce queList
estCollection
etCollection
estIterable
? Je pense que c'est faux. cochez cette répondre à partir de oracle technicien qui connaît les designers de la collection. Fondamentalement, mon point est, Il ne fait pas de sens pour étendre uneinterface
de conception de point de vue.public interface List extends Collection{}
voulez-vous dire,List
est-unIterable
, Parce queList
est-unCollection
etCollection
est-unIterable
?Oui, il y a une grande différence.
Dans votre premier exemple, votre nouvelle interface B est défini pour s'étendre à partir d'Un, afin d'aller de l'avant, tout classe qui implémente B automatiquement implémente R. en fait, vous dites que le compilateur "voici ce que signifie être Un, voici ce que cela signifie d'être un B, et oh, par ailleurs, tous les B sont également l'Un des!" Qui vous permet de dire des choses comme...
et qui fonctionne très bien.
Mais, dans votre deuxième exemple, vous ne déclarez pas B pour étendre Un, de sorte que le code ci-dessus ne fonctionnerait pas. Lorsque vous essayez d'affecter une instance de (la deuxième) C dans le cadre d'un renvoi, il serait en plaindre, parce que vous n'ai pas dit au compilateur que "tous les B sont vraiment Un de l'." (c'est à dire il n'y a aucun rapport entre
B
etC
)Si vous ne voulez pas B à être mis en œuvre sans la mise en œuvre d'Une vous pouvez faire B extends A.
Exemple:
Il est possible d'être un livingThing sans être un chien, mais il n'est pas possible d'être un chien sans être un livingThing. Donc, si on peut l'écorce il peut aussi manger, mais l'inverse n'est pas toujours vrai.
Ce que vous dites est juste, mais ce n'est pas seulement de faire connaître nos travaux, ce qui, si l'exigence est comme ceci:
1) Imaginez qu'il y a 10 interfaces n'ont pas été conçus en même temps. Par exemple, AutoCloseable interface en Java 7. Une nouvelle fermeture automatique fonctionnalité a été ajoutée, il n'y a pas jusqu'à la version 6 de Java.
2) Si vous avez conçu une interface C, qui est un marqueur de l'interface et vous souhaitez que toutes les classes dérivées à partir d'une donnée de la classe B pour le marquage, la meilleure solution serait d'utiliser des B extends C et ne va pas et de mettre de l'implémente C partout.
Il y a beaucoup plus de raisons. Si vous regardez l'image plus grande des classes et la hiérarchie, vous pourriez obtenir la réponse vous-même.
Heureux de vous Aider
Dharam
il y a seulement un commentaire en
si vous déclarez Une a = new C();
vous NE pouvez pas appeler method2(); parce que l'interface ne sait rien au sujet des éléments de l'interface B même vous met en œuvre des méthodes dans la classe C
La principale différence ici est que dans votre premier exemple B est Un et puis certains. Cela signifie que l'Interface B appels method1() et method2(), où, comme dans le second, A et B sont distincts (interface B NE permet PAS de conclure method1 ()), et de classe C implémente A et B. Dans les intances de Classe C remplace method1() et method2(). J'espère que cela aide!