Chapitre 7 - Polymorphisme

Chaque classe dans la hiérarchie contient également un objet de la classe Characteristic. Vous constaterez que les objets de Characteristic sont toujours finalisés indépendamment de l’appel conditionné des finaliseurs de la classe de base.

Chaque méthode finalize() redéfinie doit au moins avoir accès aux membres protected puisque la méthode finalize() de la classe Object est protected et le que compilateur ne vous permettra pas de réduire l'accès pendant l'héritage (« Friendly » est moins accessible que protected).

Dans Frog.main(), l'indicateur DoBaseFinalization est configuré et un seul objet Frog est créé. Rappelez-vous que la phase de garbage collection, et en particulier la finalisation, ne peut pas avoir lieu pour un objet particulier, ainsi pour la forcer, l'appel à System.gc() déclenche le garbage collector, et ainsi la finalisation. Sans finalisation de la classe de base, l'output est le suivant :

Vous pouvez constater qu'aucune finalisation n'est appelée pour les classes de base de Frog (les objets membres, eux, sont achevés, comme on s'y attendait). Mais si vous ajoutez l'argument « finalize » sur la ligne de commande, on obtient ce qui suit :

Bien que l'ordre de finalisation des objets membres soit le même que l'ordre de création, l'ordre de finalisation des objets est techniquement non spécifié. Cependant, vous avez le contrôle sur cet ordre pour les classes de base. Le meilleur ordre à suivre est celui qui est montré ici, et qui est l'ordre inverse de l'initialisation. Selon le modèle qui est utilisé pour des destructeurs en C++, vous devez d'abord exécuter la finalisation des classes dérivées, puis la finalisation de la classe de base. La raison est que la finalisation des classes dérivées pourrait appeler des méthodes de la classe de base qui exigent que les composants de la classe de base soient toujours vivants, donc vous ne devez pas les détruire prématurément.

Comportement des méthodes polymorphes dans les constructeurs

La hiérarchie d'appel des constructeurs pose un dilemme intéressant. Qu'arrive t-il si à l'intérieur d'un constructeur vous appelez une méthode dynamiquement attachée de l'objet en cours de construction? À l'intérieur d'une méthode ordinaire vous pouvez imaginer ce qui arriverait: l'appel dynamiquement attaché est résolu à l'exécution parce que l'objet ne peut pas savoir s'il appartient à la classe dans laquelle se trouve la méthode ou bien dans une classe dérivée. Par cohérence, vous pourriez penser que c'est ce qui doit arriver dans les constructeurs.

Ce n'est pas ce qui se passe. Si vous appelez une méthode dynamiquement attachée à l'intérieur d'un constructeur, c'est la définition redéfinie de cette méthode est appelée. Cependant, l'effet peut être plutôt surprenant et peut cacher des bugs difficiles à trouver.

Le travail du constructeur est conceptuellement d'amener l'objet à l'existence (qui est à peine un prouesse ordinaire). À l'intérieur de n'importe quel constructeur, l'objet entier pourrait être seulement partiellement formé - vous pouvez savoir seulement que les objets de la classe de base ont été initialisés, mais vous ne pouvez pas connaître les classes filles qui hérite de vous. Cependant, un appel de méthode dynamiquement attaché, atteint « extérieurement » la hiérarchie d'héritage. Il appelle une méthode dans une classe dérivée. Si vous faites ça à l'intérieur d'un constructeur, vous appelez une méthode qui pourrait manipuler des membres non encore initialisés - une recette très sûre pour le désastre.

Vous pouvez voir le problème dans l'exemple suivant :

Dans Glyph, la méthode dessiner [draw()] est abstraite; elle a donc été conçue pour être redéfinie. En effet, vous êtes forcés de la redéfinir dans RoundGlyph. Mais le constructeur de Glyph appelle cette méthode et l'appel aboutit à RoundGlyph.draw(), ce qui semble être l'intention. Mais regardez l'output :

Quand le constructeur de Glyph appelle draw(), le rayon [radius] n'a même pas encore la valeur initiale de 1, il vaut zéro. Le résultat serait probablement réduit à l'affichage d'un point ou même à rien du tout, avec vous, fixant un écran désespérément vide essayant de comprendre pourquoi le programme ne marche pas.

L'ordre de l'initialisation décrit dans la section précédente n'est pas complètement exhaustif, et c'est la clé qui va résoudre le mystère. La procédure d'initialisation est la suivante :

1. La zone allouée à l'objet est initialisée à zéro binaire avant tout.
2. Les constructeurs des classes de base sont appelés comme décrit précédemment. Puis, la méthode draw() redéfinie est appelée (et oui, avant l'appel du constructeur de RoundGlyph), et utilise radius qui vaut zéro à cause de la première étape.
3. Les initialiseurs des membres sont appelés dans l'ordre de déclaration.
4. Le corps du constructeur de la classe dérivée est appelé

Le bon coté est que tout est au moins initialisé au zéro (selon la signification de zéro pour un type de donnée particulier) et non laissé avec n'importe quelles valeurs. Cela inclut les références d'objet qui sont incorporés à l'intérieur d'une classe par composition, et qui passent à null. Ainsi si vous oubliez d'initialiser une référence vous obtiendrez une exception à l'exécution. Tout le reste est à zéro, qui est habituellement une valeur que l'on repère en examinant l'output.

D'autre part, vous devez être assez horrifiés du résultat de ce programme. Vous avez fait une chose parfaitement logique et pourtant le comportement est mystérieusement faux, sans aucune manifestation du compilateur (C ++ a un comportement plus correct dans la même situation). Les bugs dans ce goût là peuvent facilement rester cachés et nécessiter pas mal de temps d'investigation.

Il en résulte la recommandation suivante pour les constructeurs: « Faire le minimum pour mettre l'objet dans un bon état et si possible, ne pas appeler de méthodes. » Les seules méthodes qui sont appelables en toute sécurité à l'intérieur d'un constructeur sont celles qui sont finales dans la classe de base (même chose pour les méthodes privées, qui sont automatiquement finales.). Celles-ci ne peuvent être redéfinies et ne réservent donc pas de surprise.

Concevoir avec l'héritage

Après avoir vu le polymorphisme, c'est un instrument tellement astucieux qu'on dirait que tout doit être hérité. Ceci peut alourdir votre conception; en fait si vous faites le choix d'utiliser l'héritage d'entrée lorsque vous créez une nouvelle classe à partir d'une classe existante, cela peut devenir inutilement compliqué.

Une meilleure approche est de choisir d'abord la composition, quand il ne vous semble pas évident de choisir entre les deux. La composition n'oblige pas à concevoir une hiérarchie d'héritage, mais elle est également plus flexible car il est alors possible de choisir dynamiquement un type (et son comportement), alors que l'héritage requiert un type exact déterminé au moment de la compilation. L'exemple suivant l'illustre :

Un objet Stage contient une référence vers un Actor, qui est initialisé par un objet HappyActor. Cela signifie que go() produit un comportement particulier. Mais puisqu'une référence peut être reliée à un objet différent à l'exécution, une référence à un objet SadActor peut être substituée dans a et alors le comportement produit par go() change. Ainsi vous gagnez en flexibilité dynamique à l'exécution (également appelé le State Pattern. Voir Thinking in Patterns with Java, téléchargeable sur www.BruceEckel.com.). Par contre, vous ne pouvez pas décider d'hériter différemment à l'exécution; cela doit être complètement déterminé à la compilation.

Voici une recommandation générale: « Utilisez l'héritage pour exprimer les différences de comportement, et les champs pour exprimer les variations d'état. » Dans l'exemple ci-dessus, les deux sont utilisés: deux classes différentes héritent pour exprimer la différence dans la méthode act(), et Stage utilise la composition pour permettre à son état d'être changé. Dans ce cas, ce changement d'état provoque un changement de comportement.

Héritage pur contre extension

Lorsque l'on étudie l'héritage, il semblerait que la façon la plus propre de créer une hiérarchie d'héritage est de suivre l'approche « pure. » A savoir que seules les méthodes qui ont été établies dans la classe de base ou l'interface sont surchargeables dans la classe dérivée, comme le montre ce diagramme :

Ceci peut se nommer une relation « est-un » pure car l'interface d'une classe établie ce qu'elle est. L'héritage garantie que toute classe dérivée aura l'interface de la classe de base et rien de moins. Si vous suivez le diagramme ci-dessus, les classes dérivées auront également pas plus que l'interface de la classe de base.

Ceci peut être considéré comme une substitution pure, car les objets de classe dérivée peuvent être parfaitement substitués par la classe de base, et vous n'avez jamais besoin de connaître d' information supplémentaire sur les sous-classes quand vous les utilisez :

Cela étant, la classe de base peut recevoir tout message que vous pouvez envoyer à la classe dérivée car les deux ont exactement la même interface. Tout ce que vous avez besoin de faire est d'utiliser l'upcast à partir de la classe dérivée et de ne jamais regarder en arrière pour voir quel type exact d'objet vous manipulez.

En la considérant de cette manière, une relation pure « est-un » semble la seule façon sensée de pratiquer, et toute autre conception dénote une réflexion embrouillée et est par définition hachée. Ceci aussi est un piège. Dès que vous commencez à penser de cette manière, vous allez tourner en rond et découvrir qu'étendre l'interface (ce que, malencontreusement, le mot clé extends semble encourager) est la solution parfaite à un problème particulier. Ceci pourrait être qualifié de relation « est-comme-un » car la classe dérivée est comme la classe de base, elle a la même interface fondamentale mais elle a d'autres éléments qui nécessitent d'implémenter des méthodes additionnelles :

Mais si cette approche est aussi utile et sensée (selon la situation) elle a un inconvénient. La partie étendue de l'interface de la classe dérivée n'est pas accessible à partir de la classe de base, donc une fois que vous avez utilisé l'upcast vous ne pouvez pas invoquer les nouvelles méthodes :

Si vous n'upcastez pas dans ce cas, cela ne va pas vous incommoder, mais vous serez souvent dans une situation où vous aurez besoin de retrouver le type exact de l'objet afin de pouvoir accéder aux méthodes étendues de ce type. La section suivante montre comment cela se passe.

Downcasting et identification du type à l'exécution

Puisque vous avez perdu l'information du type spécifique par un upcast (en remontant la hiérarchie d'héritage), il est logique de retrouver le type en redescendant la hiérarchie d'héritage par un downcast. Cependant, vous savez qu'un upcast est toujours sûr; la classe de base ne pouvant pas avoir une interface plus grande que la classe dérivée, ainsi tout message que vous envoyez par l'interface de la classe de base a la garantie d'être accepté. Mais avec un downcast, vous ne savez pas vraiment qu'une forme (par exemple) est en réalité un cercle. Cela pourrait plutôt être un triangle ou un carré ou quelque chose d'un autre type.

Pour résoudre ce problème il doit y avoir un moyen de garantir qu'un downcast est correct, ainsi vous n'allez pas effectuer un cast accidentel vers le mauvais type et ensuite envoyer un message que l'objet ne pourrait accepter. Ce serait assez imprudent.

Dans certains langages (comme C++) vous devez effectuer une opération spéciale afin d'avoir un cast ascendant sûr, mais en Java tout cast est vérifié! Donc même si il semble que vous faites juste un cast explicite ordinaire, lors de l'exécution ce cast est vérifié pour assurer qu'en fait il s'agit bien du type auquel vous vous attendez. Si il ne l'est pas, vous récupérez une ClassCastException. Cette action de vérifier les types au moment de l'exécution est appelé run-time type identification (RTTI). L'exemple suivant montre le comportement de la RTTI :

Comme dans le diagramme, MoreUseful étend l'interface de Useful. Mais puisque il a hérité, on peut faire un transtypage ascendant vers un Useful. Vous pouvez voir ceci se produire dans l'initialisation du tableau x dans main( ). Comme les deux objets du tableau sont de la classe Useful, vous pouvez envoyer les méthodes f( ) et g( ) aux deux, et si vous essayer d'invoquer u( ) (qui existe seulement dans MoreUseful), vous aurez un message d'erreur à la compilation.