Différences

Ci-dessous, les différences entre deux révisions de la page.

--- java:abstract [2013/11/07 14:42] – [Et si je ne veux pas redéfinir une méthode abstraite, hein?] 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 ======
+> "Le concret c'est de l'abstrait rendu familier par l'usage." (Paul Longevin)
 Nous voyons aujourd'hui dans ce TP guidé un concept qui porte malheureusement bien souvent son nom: **abstract**.
-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 à tord et à travers.
+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 à tord et à travers.
 Heureusement, dans 30 minutes maximum, vous constaterez que c'est en réalité **très** simple!
@@ Ligne 8: / Ligne 11: @@
 C'est parti!
-===== Un peu de théorie histoire de bien situer le contexte =====
+===== Un peu de théorie histoire de bien situer la problématique =====
-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'avance, mais j'aimerais bien voir Nietzsche à ma place ;-)).
 Vous savez normalement ce qu'est l'héritage. Ce concept est directement lié à l'utilisation de //abstract//.
@@ Ligne 18: / Ligne 23: @@
 Ces classes mères permettent avant tout de donner une direction générale à la programmation, au //modèle//, mais ne peuvent pas toujours tout prévoir.
-Nous savons qu'il est possible de //redéfinir// des comportements (par exemple, //toString()//, //equals()//, etc.
+Nous savons qu'il est possible de //redéfinir// des comportements (par exemple, //toString()//, //equals()//, etc.).
 Mais pour l'instant, nous ne savons pas encore comment contraindre les héritiers à préciser leur comportement en redéfinissant des méthodes.
@@ Ligne 507: / Ligne 512: @@
 Apparemment, le compilateur semble contrarié. Regardons en détail ce qu'il nous raconte:
-"Chat n'est pas abstract" -> ok
+> "Chat n'est pas abstract" -> ok
-"...et ne redéfinie pas la méthode abstraite jouer(Animal)" -> on vient de la commenter...
+> "...et ne redéfinit pas la méthode abstraite jouer(Animal)" -> on vient de la commenter...
 Quel problème cela pose-t-il pour le compilateur: raisonnons par l'absurde.
@@ Ligne 525: / Ligne 530: @@
   - soit redéfinir la méthode //jouer// dans Chat, pour permettre la construction d'instances de Chat.
+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 //ChatJoueur//) et que le programmeur veut créer des instances de //ChatJoueur//, il devra alors redéfinir la méthode //jouer// héritée de Animal par l'intermédiaire de //Chat// dans la classe //ChatJoueur//: on appelle ça "refiler la patate chaude".
+===== Pour aller encore plus loin: les classes virtuelles pures (ou interfaces en java) =====
+-> ce dernier point fait l'objet d'un autre TP guidé...