Par exemple, lors de la création d'une classe appelée "sportif" / "lecteur" à partir d'une classe appelée "humain" (manger, marcher, dormir), chaque classe "sportif" / "lecteur" est héritée de la classe humaine. La quantité de (manger, dormir) est différente. (Les sportifs mangent plus que les lecteurs, et les lecteurs restent éveillés tard pour dormir moins que les sportifs fatigués et bien dormir.) Dans ce cas, la classe humaine ne peut pas définir les détails sur (manger, dormir). Cependant, les êtres humains font toujours (manger, marcher, dormir), qu'ils soient "sportifs" ou "lecteurs". D'un point de vue orienté objet, ce que vous faites dans une classe humaine doit être décrit dans la classe humaine. Fonction pour ça.
Dans l'exemple ci-dessus, (eat, sleep) est une méthode dont les détails ne peuvent pas être définis, donc elle peut être définie comme une méthode incomplète en ajoutant ʻabstract` lors de la création de la méthode.
//Définition de la méthode
Résumé du modificateur d'accès Valeur de retour Nom de la méthode (argument);
En déclarant une méthode avec ʻabstracrt`, vous pouvez définir une méthode d'une classe ambiguë et obtenir les effets suivants.
-Si vous ne le remplacez pas et ne l'implémentez pas, une erreur se produira, alors évitez d'oublier de le remplacer. ・ Il est possible de faire la distinction entre la définition qui ne peut être définie et la définition qui "ne rien faire".
De même, comment définir une classe avec des méthodes ambiguës, comme la classe "humaine" ci-dessus, est la suivante.
//Définition de classe
Classe abstraite du modificateur d'accès Valeur de retour Nom de la classe (argument);
Les classes avec même une méthode ambiguë doivent toujours avoir «abstrait».
-Parce qu'il ne peut pas être créé en tant qu'instance, il empêche l'instanciation accidentelle.
・ Toutes les méthodes sont des méthodes abstraites utilisant ʻabstract`
Interface du modificateur d'accès Nom de l'interface (argument);
Le nom de classe de la classe de modificateur d'accès implémente le nom de l'interface parent{
}
implémenter = moyen de mettre en œuvre
L'implémentation d'une interface force l'implémentation de la méthode et garantit qu'au moins les membres qui ont cette interface l'auront.
-Les méthodes d'interface sont automatiquement marquées avec ** résumé public ** -Le champ d'interface est toujours marqué avec ** public static final ** ・ L'héritage multiple est possible * Les détails sont décrits ci-dessous
--------------- (exemple gênant) --------------- ・ Classe humaine "Méthode de déplacement" Marcher et bouger
・ Classe du diable "Méthode de déplacement" Voler et se déplacer ↓ Héritage multiple pour générer Devilman!
・ Classe Devilman
"Méthode de déplacement" Laquelle doit être héritée ...? ?? ?? ――――――――――――――――――――――――――――――――――――――――――
---------- (Pour les interfaces) --------------- ・ Interface humaine "Méthode de déplacement" non implémentée ・ Interface du diable "Méthode de déplacement" non implémentée
↓ Héritage multiple pour générer Devilman!
・ Classe Devilman
Implémentation de la "méthode de déplacement": voler et bouger
――――――――――――――――――――――――――――――――――――――――――
En bref, diverses classes peuvent avoir des méthodes telles que move
, il y a donc un risque de conflits d'implémentation.
Cependant, dans le cas d'une interface, puisqu'elle n'est pas implémentée, même si une méthode est couverte, elle est implémentée dans une interface enfant, donc il n'y a pas de conflit. Par conséquent, ** l'interface peut être héritée plusieurs fois. ** **
Le nom de classe de la classe du qualificateur d'accès implémente le nom de l'interface parent 1,Nom de l'interface parent 2 ...{
}
Le nom de classe de la classe du qualificateur d'accès étend le nom de la classe parent implémente le nom de l'interface parent 1,Nom de l'interface parent 2 ...{
}
Source d'héritage | Destination d'héritage | Mots utilisés pour l'héritage | Nombre de sources d'héritage |
---|---|---|---|
classe | classe | extend | 1 |
interface | classe | implement | Un ou plus |
interface | interface | extend | Un ou plus |
Recommended Posts