Classes abstraites et méthodes retardées
291
On pourra alors instancier des objets de type B1 :
B b
B1 b1
b1 := Création B1(...)
// OK
b := Création B1(...)
// OK
b := Création B(...)
// erreur
Bien entendu, il reste possible de définir comme abstraite une classe dérivée d’une classe
abstraite. Dans ce cas, la redéfinition des méthodes retardées n’est pas obligatoire. Elle devra
simplement être faite dans toute classe dérivée ultérieure qu’on souhaite pouvoir instancier :
classe abstraite B2 dériveDe B
{ .....
// ici, on n’est pas obligé de définir la méthode g
}
1.3 Intérêt des classes abstraites et des méthodes retardées
Le recours aux classes abstraites et aux méthodes retardées facilite largement la conception
des logiciels. En effet, on peut placer dans une classe abstraite toutes les fonctionnalités dont
on souhaite disposer pour toutes ses descendantes :
• soit sous forme d’une implémentation complète de méthodes (non retardées) et d’attributs
(privés ou non) lorsqu’ils sont communs à toutes ses descendantes,
• soit sous forme d’interfaces (signature + type du résultat) de méthodes retardées dont on est
alors certain qu’elles existeront dans toute classe dérivée instanciable.
C’est cette certitude de la présence de certaines méthodes qui permet d’exploiter le polymorphisme, et ce dès la conception de la classe abstraite, alors même qu’aucune classe dérivée
n’a peut-être encore été créée. Notamment, on peut très bien écrire des canevas recourant à
des méthodes abstraites. Par exemple, si vous avez défini :
classe abstraite X
{ méthode retardée f()
// ici, f n’est pas encore définie
.....
}
vous pourrez écrire une méthode (d’une classe quelconque), disposant d’un paramètre de
type X, telle que :
méthode algo (X x)
// en paramètre, x de type X
{ .....
x.f()
// appel correct car on est sûr que tout objet
.....
// d’une classe dérivée de X disposera bien d’une méthode f
}
Bien entendu, tout appel de la méthode algo devra utiliser, en paramètre effectif, une
référence à un objet d’un type dérivé de X.