“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 301 — #311
i
i
i
i
i
i
i
i
6.4 La programmation avec l’héritage
301
simple et multiple pour cet exemple ? Dans les deux cas, les figures qui font la figure
composite sont encapsulées. La différence principale est que l’héritage multiple place
les opérations de la liste enchaînée au même niveau que la figure :
– Avec l’héritage multiple, une figure composite est aussi une liste enchaînée.
Toutes les opérations de la classe LinkedList peuvent être utilisées directement sur les figures composites. C’est important si nous voulons faire des calculs
de liste enchaînée sur les figures composites.
– Avec l’héritage simple, une figure composite cache complètement sa structure.
C’est important si nous voulons protéger la figure composite de tous les calculs
sauf ceux définis dans sa classe.
6.4.3 Quelques règles de conception pour l’héritage multiple
L’héritage multiple est une technique puissante à utiliser avec prudence. Nous vous
recommandons de l’utiliser selon les règles suivantes :
– L’héritage multiple fonctionne bien pour combiner deux abstractions qui sont
complètement indépendantes. Par exemple, les figures et les listes enchaînées ne
partagent rien, elles peuvent donc être combinées avec succès.
– L’héritage multiple est bien plus difficile à utiliser correctement quand les abstractions partagent quelque chose. Par exemple, la création d’une classe WorkStudy
à partir de Student et Employee est douteuse, parce que les étudiants et les
employés sont tous les deux des êtres humains. Ils peuvent tous les deux hériter
d’un ancêtre commun, une classe Person ! Même s’ils n’ont pas d’ancêtre
commun, il peut y avoir des problèmes s’ils partagent des concepts.
– Que se passe-t-il quand deux superclasses frères partagent (directement ou indirectement) une classe ancêtre en commun qui spécifie un objet avec état (avec des
attributs) ? Cette situation s’appelle le problème d’implémentation partagée.
Elle peut mener à des opérations dupliquées sur l’ancêtre commun, par exemple
quand on initialise un objet. La méthode d’initialisation doit normalement initialiser ses superclasses, l’ancêtre commun est donc initialisé deux fois. Le seul
remède est de bien comprendre la hiérarchie pour éviter une telle duplication.
Une alternative est de n’hériter que des classes qui ne partagent pas un ancêtre
commun avec état.
– Quand il y a un conflit de nom entre deux méthodes, c’est-à-dire que la même
étiquette est utilisée dans des superclasses adjacentes, alors le programme doit
définir une méthode locale qui redéfinit les méthodes conflictuelles. Sinon le
système à objets donne un message d’erreur. Une manière simple d’éviter ces
conflits est d’utiliser des valeurs de nom comme étiquettes de méthodes. C’est
une bonne technique pour certaines classes, comme les classes mixin, qui sont
souvent utilisées dans l’héritage multiple.
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
6.4 La programmation avec l’héritage
301
simple et multiple pour cet exemple ? Dans les deux cas, les figures qui font la figure
composite sont encapsulées. La différence principale est que l’héritage multiple place
les opérations de la liste enchaînée au même niveau que la figure :
– Avec l’héritage multiple, une figure composite est aussi une liste enchaînée.
Toutes les opérations de la classe LinkedList peuvent être utilisées directement sur les figures composites. C’est important si nous voulons faire des calculs
de liste enchaînée sur les figures composites.
– Avec l’héritage simple, une figure composite cache complètement sa structure.
C’est important si nous voulons protéger la figure composite de tous les calculs
sauf ceux définis dans sa classe.
6.4.3 Quelques règles de conception pour l’héritage multiple
L’héritage multiple est une technique puissante à utiliser avec prudence. Nous vous
recommandons de l’utiliser selon les règles suivantes :
– L’héritage multiple fonctionne bien pour combiner deux abstractions qui sont
complètement indépendantes. Par exemple, les figures et les listes enchaînées ne
partagent rien, elles peuvent donc être combinées avec succès.
– L’héritage multiple est bien plus difficile à utiliser correctement quand les abstractions partagent quelque chose. Par exemple, la création d’une classe WorkStudy
à partir de Student et Employee est douteuse, parce que les étudiants et les
employés sont tous les deux des êtres humains. Ils peuvent tous les deux hériter
d’un ancêtre commun, une classe Person ! Même s’ils n’ont pas d’ancêtre
commun, il peut y avoir des problèmes s’ils partagent des concepts.
– Que se passe-t-il quand deux superclasses frères partagent (directement ou indirectement) une classe ancêtre en commun qui spécifie un objet avec état (avec des
attributs) ? Cette situation s’appelle le problème d’implémentation partagée.
Elle peut mener à des opérations dupliquées sur l’ancêtre commun, par exemple
quand on initialise un objet. La méthode d’initialisation doit normalement initialiser ses superclasses, l’ancêtre commun est donc initialisé deux fois. Le seul
remède est de bien comprendre la hiérarchie pour éviter une telle duplication.
Une alternative est de n’hériter que des classes qui ne partagent pas un ancêtre
commun avec état.
– Quand il y a un conflit de nom entre deux méthodes, c’est-à-dire que la même
étiquette est utilisée dans des superclasses adjacentes, alors le programme doit
définir une méthode locale qui redéfinit les méthodes conflictuelles. Sinon le
système à objets donne un message d’erreur. Une manière simple d’éviter ces
conflits est d’utiliser des valeurs de nom comme étiquettes de méthodes. C’est
une bonne technique pour certaines classes, comme les classes mixin, qui sont
souvent utilisées dans l’héritage multiple.
© Dunod – La photocopie non autorisée est un délit