Lisaac/Héritage
Question : Bon comme c'est censé être un langage objet certifié élevé au grain : voyons directement comment hériter d'une classe ? pardon d'un prototype.
[modifier | modifier le wikicode]Facile (heureusement) il faut rajouter un identifiant dans la section Inherit et lui affecter le nom du prototype. Dans l'exemple suivant j'ai rajouté un héritage vers le parent racine de tous les prototypes le bien nommé : OBJECT.
Section Header + name := TOTO; - category := APPLICATION; section Inherit - parent_object:OBJECT := OBJECT;
Lisaac autorise plusieurs types d'héritages qui seront abordés dans le deuxième chapitre. L'héritage présenté dans l'exemple ci-dessus est particulier, puisqu'il n'a pas le comportement habituel des langages objet à classes. Pour retrouver ce type de comportement, il faut utiliser la forme suivante :
Section Inherit + heritage_standard:Expanded PROTO_PARENT;
Ce qui dénote un héritage expansé non partagé.
Q : Étrange j'ai l'habitude que la classe racine soit ajoutée automatiquement comme en Java, N'est-ce pas revenir aux problèmes du C++ qui ne proposait pas de classe racine ?
[modifier | modifier le wikicode]Pas vraiment, le problème principal en C++ venait surtout du fait que la classe Object n'était pas fournie en standard avec les compilateurs. Ici vous devez ajouter le prototype parent Objet à la main mais elle est standard donc pas de soucis. Et en plus vous pouvez adapter le système en utilisant votre propre prototype "Adam" pour des besoin spécifiques.
Q : Et je peux rajouter autant d'héritage que je veux ?
[modifier | modifier le wikicode]Bien sur lisaac gère l'héritage multiple ! Et vous êtes encouragé à l'utiliser !
Q : Mais je croyais que l'héritage multiple était le MAL et qu'il ne fallait pas l'utiliser. Et même que c'est révélateur d'un mauvaise conception objet !!
[modifier | modifier le wikicode]Pas du tout cela fait longtemps que l'on sait résoudre les problème du multi-héritage correctement. C'est juste que la solution proposée par C++ est bancale. Et que le l'idée de se restreindre à l'héritage simple + interface multiple (comme en Java,C#,Smalltalk,...) règle évidement tous les problèmes mais empêche aussi d'utiliser le concept d'héritage à sa pleine mesure. Sachez enfin que l'héritage multiple ne pose des difficultés que lorsque le graphe d'héritage possède un ou plusieurs cycles (problème du diamant). En dehors de ce cas il n'y a pas vraiment de différence avec l'héritage simple, sauf que c'est plus utile. Et nous parlerons des cas problématiques dans la deuxième partie du tutoriel.
Q : Je trouve cela étrange que l'on doive nommer la relation d'héritage, on dirait une relation d'agrégation !
[modifier | modifier le wikicode]Oui mais cela n'en est pas une, les relations d'héritage sont nommées c'est tout. Et c'est logique puisque l'on peut en avoir plusieurs, et cela permet aussi d'autres choses que nous verrons plus tard.
Q : Que signifie ces '+' et '-' devant la déclaration d'héritage, ainsi que Expanded ?
[modifier | modifier le wikicode]- Le '-' signifie que l'héritage est partagé. Concrètement l'objet parent existe de manière indépendante et unique en mémoire et est partagé pour toutes les instances.
- Le '+' signifie que l'héritage n'est pas partagé. Donc l'objet parent existe de manière indépendante et multiple en mémoire et chaque instance peut avoir le sien.
- Le Expanded devant le type dénote que l'objet parent n'existe pas de manière indépendante en mémoire. Il est inclus dans la représentation mémoire de l'instance.
