Cours 6 0. Rappels sur l'héritage 0.1 Syntaxe: public class Fille extends Mere { ..., exemple: Forme { aX, aY, depVertical(), dessine(), dessineSpec() } et Cercle extends Forme { aDiametre, dessineSpec() } et Carre extends Forme { aCote, dessineSpec() } 0.2 Hérite de : tous les attributs et méthodes (non privées) sauf les constructeurs, mais on ne peut accéder aux attributs privés, ni redéfinir les méthodes privées. 0.3 protected : déconseillé pour les attributs, OK pour les méthodes, et super.methode(); et super(...); et @Override 0.4 type déclaré/constaté : - conversion: du type déclaré, car on ne peut changer la nature de l'objet (type constaté) - liaison dynamique ==> toujours la méthode la plus appropriée - Cercle c = obj; ==> erreur de compilation ≠ Cercle c = (Cercle)obj; ==> erreur à l'exécution (exception si obj n'est pas un Cercle) 0.5 Object : mère de toutes les classes, méthodes à redéfinir : toString, equals, finalize et non redéfinissable : getClass() I. Abstraction I.1 Classe abstraite I.1.a Forme vF = new Forme( ); vF.dessine( ); --> dessineSpec( ) "bidon" I.1.b interdire l'instanciation, mais laisser en commun ce qui doit l'être; classe prévue pour être dérivée I.1.c constructeurs : utiles pour initialiser les attributs communs; appelés par super(...); I.1.d syntaxe: abstract (public abstract class NomClasse ...) I.2 Méthode abstraite I.2.a interdire l'exécution ==> pas de corps, évite les corps "bidon" (dessineSpec()) I.2.b redéfinition obligatoire dans toutes les sous-classes (sinon elles seront abstraites) ==> ne concerne pas les constructeurs, private interdit, @Override . Garantit une cohérence, un contrat avec les sous-classes, y compris les futures ==> extensibilité. I.2.c syntaxe: abstract et ; au lieu de {} (public abstract void nomMethode( ) ; ) I.2.d Si dans une classe il existe une méthode abstraite (non redéfinie), cette classe est abstraite (==> abstract) car objet.methode() doit toujours pouvoir marcher si objet a pu être instancié I.2.e dessine() peut quand-même appeler dessineSpec() grâce à la liaison dynamique ==> utilisation de classes non encore écrites ==> garantie d'extensibilité I.2.f Il est évident qu'une classe non abstraite peut hériter d'une classe abstraite, mais il est aussi possible qu'une classe abstraite hérite d'une classe non abstraite. I.2.g Dans le JDK : implémentations partielles I.3 Interface (pour compenser l'absence d'héritage multiple) I.3.a et si 100% des méthodes étaient abstraites ? et aucune variable d'instance ? I.3.b 100% des méthodes public abstract ==> 2 mots inutiles, et pas de constructeurs I.3.c 100% des attributs public static final ==> 3 mots inutiles I.3.d 100% des méthodes à redéfinir ==> pas de @Override (car pas d'extends) I.3.e syntaxe: interface au lieu de abstract class , implements au lieu de extends , une classe peut implémenter plusieurs interfaces (séparées par des virgules) ==> implémenter toutes les méthodes de toutes les interfaces ! I.3.f exemple d'interfaces: ActionListener ==> actionPerformed(...) Dessinable ==> dessine() Comparable ==> compareTo() Forme implements Comparable, Dessinable Cercle extends Forme Rosace implements Dessinable I.3.g exemple d'objet: Dessinable obj = new Cercle(); obj.dessine(); plutôt que Cercle obj = new Cercle(); I.3.h classe anonyme: 1) bouton.addActionListener( this ); ==> la classe courante contient actionPerformed(...) 2) bouton.addActionListener( myButtonListener ); ==> myButtonListener est une instance d'une classe contenant actionPerformed(...) 3) bouton.addActionListener( new ActionListener() { public void actionPerformed(...) { instructions } } ); ==> rien de plus ! (classe anonyme) équivalent à (remplace avantageusement) : private class Circle$1 implements ActionListener { public void actionPerformed(...) { instructions } } // Circle$1 bouton.addActionListener( new Circle$1() ); I.3.i héritage d'interfaces: si interface SousI extends SuperI , on devra implémenter toutes les méthodes de SousI et SuperI héritage multiple ! ==> interface sousI extends superI1, superI2 I.3.j véritable type ==> l'opérateur instanceof fonctionne; comme pour une super-classe (abstraite ou non) : réfObjet instanceof ClasseOuInterface II. Exceptions II.1 Résumé de cours II.2 Essayer la classe de démonstration et comprendre les affichages II.3 Hiérarchie des exceptions du paquetage java.lang II.4 Tutoriel (en anglais) Lire le poly : tout jusqu'à la section 2.4.1, 2.4.2, sections 2.5, 3.1, 3.2, 3.2.2, 3.3, 3.6, 4, 5.1, 5.2.0, 6, 7.1, 7.2, 8.1, 8.2.1.1, 8.2.2, 9.1 à 9.5, 9.6, 9.7, 10, 13.3, et annexes 6 & 7

Dernière mise à jour :