java:abstract
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
java:abstract [2013/11/07 14:26] – bruno | java:abstract [2018/03/16 15:42] (Version actuelle) – [Pour aller encore plus loin: les classes virtuelles pures (ou interfaces en java)] bruno | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
====== Abstract et java ====== | ====== Abstract et java ====== | ||
+ | |||
+ | > "Le concret c'est de l' | ||
+ | |||
Nous voyons aujourd' | Nous voyons aujourd' | ||
- | En effet, très souvent, les débutants en java et plus généralement en objet ne comprennent pas à quoi il sert, et donc l'utilise | + | En effet, très souvent, les débutants en java et plus généralement en objet ne comprennent pas à quoi il sert, et donc l'utilisent |
Heureusement, | Heureusement, | ||
Ligne 8: | Ligne 11: | ||
C'est parti! | C'est parti! | ||
- | ===== Un peu de théorie histoire de bien situer | + | ===== Un peu de théorie histoire de bien situer |
- | Je vais commencer par un peu de théorie de la programmation orientée objet. | + | > Plus abstraite est la vérité que tu veux enseigner, plus tu dois en sa faveur séduire les sens. (Friedrich Nietzsche) |
+ | |||
+ | Je vais commencer par essayer de vous séduire avec un peu de théorie de la programmation orientée objet (certain diront que c'est pas gagné d' | ||
Vous savez normalement ce qu'est l' | Vous savez normalement ce qu'est l' | ||
Ligne 18: | Ligne 23: | ||
Ces classes mères permettent avant tout de donner une direction générale à la programmation, | Ces classes mères permettent avant tout de donner une direction générale à la programmation, | ||
- | Nous savons qu'il est possible de // | + | Nous savons qu'il est possible de // |
Mais pour l' | Mais pour l' | ||
Ligne 24: | Ligne 29: | ||
Nous allons voir ici que justement, la programmation objet permet de résoudre ces problèmes. | Nous allons voir ici que justement, la programmation objet permet de résoudre ces problèmes. | ||
- | Nous allons découvrir trois manières de traiter l' | + | Nous allons découvrir trois manières de traiter l' |
- les classes abstraites; | - les classes abstraites; | ||
- les méthodes virtuelles (ou abstraites); | - les méthodes virtuelles (ou abstraites); | ||
Ligne 162: | Ligne 167: | ||
</ | </ | ||
- | ==== Les classes abstraites ==== | + | ===== Les classes abstraites |
Dans la hiérarchie que je viens de donner, il n'est pas très utile d' | Dans la hiérarchie que je viens de donner, il n'est pas très utile d' | ||
Ligne 224: | Ligne 229: | ||
On voit bien que c'est l' | On voit bien que c'est l' | ||
- | ==== Allons un peu plus loin: les méthodes virtuelles (ou abstraites) ==== | + | ===== Allons un peu plus loin: les méthodes virtuelles (ou abstraites) |
Nous avons vu que nous pouvions interdire la création directe d' | Nous avons vu que nous pouvions interdire la création directe d' | ||
Ligne 235: | Ligne 240: | ||
**Hé bien c'est possible!** Nous allons déclarer //jouer// comme étant une méthode // | **Hé bien c'est possible!** Nous allons déclarer //jouer// comme étant une méthode // | ||
+ | |||
+ | ==== Les méthodes virtuelles ou méthodes abstraites ==== | ||
Une méthode // | Une méthode // | ||
Ligne 464: | Ligne 471: | ||
</ | </ | ||
+ | |||
+ | ==== Et si je ne veux pas redéfinir une méthode abstraite, hein? ==== | ||
+ | |||
+ | Vous vous posez peut-être cette question. | ||
+ | |||
+ | Hé bien, c'est possible! Mais pas à n' | ||
+ | |||
+ | Les chats sont paresseux, supposons que la classe Chats ne redéfinisse pas la méthode jouer. | ||
+ | |||
+ | Que va dire le compilateur? | ||
+ | |||
+ | <code java> | ||
+ | /** | ||
+ | Pour faire jouer le chat. | ||
+ | Affiche un petit message en console. | ||
+ | @param a l' | ||
+ | @return true si l' | ||
+ | */ | ||
+ | /* Je veux pas redéfinir moi! | ||
+ | public boolean jouer(Animal a){ | ||
+ | boolean ret = true; | ||
+ | String message = "Je veux bien jouer avec les instances de " + a.getClass().getName() ; | ||
+ | if(a instanceof Chien){ | ||
+ | ret=false; | ||
+ | message = "Je ne joue pas avec les chiens, moi!"; | ||
+ | } | ||
+ | System.out.println(message); | ||
+ | return ret; | ||
+ | } | ||
+ | */ | ||
+ | </ | ||
+ | |||
+ | Recompilons: | ||
+ | |||
+ | <code bash> | ||
+ | ./ | ||
+ | public class Chat extends Animal{ | ||
+ | </ | ||
+ | |||
+ | Apparemment, | ||
+ | |||
+ | > "Chat n'est pas abstract" | ||
+ | |||
+ | > "...et ne redéfinit pas la méthode abstraite jouer(Animal)" | ||
+ | |||
+ | Quel problème cela pose-t-il pour le compilateur: | ||
+ | |||
+ | Si le compilateur permettait à Chat de ne **pas** redéfinir la méthode jouer, et également de construire des instances de Chat, que se passerait-il lorsque l'on voudrait appeler la méthode // | ||
+ | |||
+ | Il n'y aurait pas de code défini -> le programme ne saurait pas quoi faire. | ||
+ | |||
+ | Le " | ||
+ | |||
+ | Donc, si ce comportement n'est pas définit dans un héritier d' | ||
+ | |||
+ | Le compilateur propose donc deux solutions: | ||
+ | - soit passer la classe Chat en classe abstraite, afin d' | ||
+ | - soit redéfinir la méthode //jouer// dans Chat, pour permettre la construction d' | ||
+ | |||
+ | Si on choisit la première solution, Chat devient abstract et il n'y a plus de problème de compilation... à condition de ne pas utiliser le constructeur //Chat// avec **new**. | ||
+ | |||
+ | Si une classe hérite de Chat (par exemple // | ||
+ | |||
+ | ===== Pour aller encore plus loin: les classes virtuelles pures (ou interfaces en java) ===== | ||
+ | |||
+ | -> ce dernier point fait l' | ||
+ | |||
java/abstract.1383834412.txt.gz · Dernière modification : 2013/11/07 14:26 de bruno