“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 271 — #281
i
i
i
i
i
i
i
i
6.1 L’héritage
271
– La section 6.4 explique les concepts et techniques de base pour programmer
avec l’héritage. Nous y introduisons la propriété de substitution (le principe le
plus important), la conception par contrat, l’héritage multiple, les diagrammes
de classe et les motifs de conception. Nous illustrons ces concepts avec des
exemples réalistes. Nous donnons des références à la littérature sur la conception
orientée objet.
– Enfin, la section 6.5 introduit le langage Java, un langage orienté objet populaire.
Nous survolons la partie séquentielle de Java. Nous montrons comment les
concepts de Java s’accordent avec le système à objets du chapitre.
Pour plus d’informations sur les techniques et principes de la programmation orientée
objet, nous recommandons le livre « Object-Oriented Software Construction » de
Bertrand Meyer [65]. Ce livre est particulièrement intéressant pour sa présentation
détaillée de l’héritage, y compris de l’héritage multiple.
6.1 L’HÉRITAGE
L’héritage est basé sur l’observation suivante : les abstractions de données ont souvent
beaucoup en commun. Prenons l’exemple des ensembles. Il y a beaucoup d’abstractions qui ressemblent aux ensembles, c’est-à-dire qu’elles sont des collections
auxquelles nous pouvons ajouter et enlever des éléments. Parfois nous voudrions
qu’elles soient comme des piles, avec un comportement dernier entré premier sorti
(DEPS) (LIFO, « last-in, first-out »). Parfois nous voudrions qu’elles soient comme
des files, avec un comportement premier entré premier sorti (PEPS) (FIFO, « first-in,
first-out »). Parfois l’ordre des entrées et sorties n’est pas important. Et ainsi de suite,
avec beaucoup d’autres possibilités. Toutes ces abstractions se partagent la propriété de
base d’être une collection d’éléments. Pouvons-nous les implémenter sans dupliquer
les parties communes ? Les parties dupliquées allongent le programme, mais ce n’est
pas tout. Elles sont un cauchemar pour le programmeur et le mainteneur, car si une des
copies est changée, il faudra changer les autres aussi. Comme les différentes copies
sont généralement légèrement différentes, les relations entre tous ces changements
sont obscures.
Nous introduisons le concept d’héritage pour réduire le problème de la duplication
du code et clarifier les relations entre les différentes abstractions. Une abstraction de
données peut « hériter » d’une ou de plusieurs autres abstractions de données, c’està-dire avoir substantiellement la même implémentation que les autres, avec peut-être
quelques extensions et modifications. Seules les différences entre l’abstraction de
données et ses ancêtres doivent être spécifiées. Une telle définition incrémentale d’une
abstraction de données s’appelle une classe.
Une nouvelle classe est définie par une sorte de transformation : une ou plusieurs
classes existantes sont combinées avec une description des extensions et modifications
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
6.1 L’héritage
271
– La section 6.4 explique les concepts et techniques de base pour programmer
avec l’héritage. Nous y introduisons la propriété de substitution (le principe le
plus important), la conception par contrat, l’héritage multiple, les diagrammes
de classe et les motifs de conception. Nous illustrons ces concepts avec des
exemples réalistes. Nous donnons des références à la littérature sur la conception
orientée objet.
– Enfin, la section 6.5 introduit le langage Java, un langage orienté objet populaire.
Nous survolons la partie séquentielle de Java. Nous montrons comment les
concepts de Java s’accordent avec le système à objets du chapitre.
Pour plus d’informations sur les techniques et principes de la programmation orientée
objet, nous recommandons le livre « Object-Oriented Software Construction » de
Bertrand Meyer [65]. Ce livre est particulièrement intéressant pour sa présentation
détaillée de l’héritage, y compris de l’héritage multiple.
6.1 L’HÉRITAGE
L’héritage est basé sur l’observation suivante : les abstractions de données ont souvent
beaucoup en commun. Prenons l’exemple des ensembles. Il y a beaucoup d’abstractions qui ressemblent aux ensembles, c’est-à-dire qu’elles sont des collections
auxquelles nous pouvons ajouter et enlever des éléments. Parfois nous voudrions
qu’elles soient comme des piles, avec un comportement dernier entré premier sorti
(DEPS) (LIFO, « last-in, first-out »). Parfois nous voudrions qu’elles soient comme
des files, avec un comportement premier entré premier sorti (PEPS) (FIFO, « first-in,
first-out »). Parfois l’ordre des entrées et sorties n’est pas important. Et ainsi de suite,
avec beaucoup d’autres possibilités. Toutes ces abstractions se partagent la propriété de
base d’être une collection d’éléments. Pouvons-nous les implémenter sans dupliquer
les parties communes ? Les parties dupliquées allongent le programme, mais ce n’est
pas tout. Elles sont un cauchemar pour le programmeur et le mainteneur, car si une des
copies est changée, il faudra changer les autres aussi. Comme les différentes copies
sont généralement légèrement différentes, les relations entre tous ces changements
sont obscures.
Nous introduisons le concept d’héritage pour réduire le problème de la duplication
du code et clarifier les relations entre les différentes abstractions. Une abstraction de
données peut « hériter » d’une ou de plusieurs autres abstractions de données, c’està-dire avoir substantiellement la même implémentation que les autres, avec peut-être
quelques extensions et modifications. Seules les différences entre l’abstraction de
données et ses ancêtres doivent être spécifiées. Une telle définition incrémentale d’une
abstraction de données s’appelle une classe.
Une nouvelle classe est définie par une sorte de transformation : une ou plusieurs
classes existantes sont combinées avec une description des extensions et modifications
© Dunod – La photocopie non autorisée est un délit