Discussion :

[SchpatziBreizh]

Petites questions :
L'héritage multiple est-il possible en delphi?
Existe-t-il des tutoriels et/ou des sources sur le sujet sur developpez.com?

Merci par avance.

[MD Software]

L'héritage multiple n'est pas possible en Delphi, car tous les objets héritent de TObject.

[Clorish]

Cependant il est possible d'y palier en faisant usage des interfaces ou de maniere plus transparente en ecrivant un objet qui contien en interne les 2 objets dont on veux "Multi-heriter" et en developpant des methdes qui ne servent qu'a faire appel aux methdoes des 2 sous objets desirés.

Sinon le multi-heritage "est une solution qui permet aux developpeur peut consciencieux de rattrapper des erreurs de conceptions" dixit en des termes similaires O.Dahan

[SchpatziBreizh]

Ok, merci pour les réponses.
En ce qui concerne la conscience, c'est bon, il n'y pas de soucis, je n'en suis qu'à la conception, je prends alors la dernière remarque comme un conseil .
Si j'ai bien compris, l'héritage multiple n'est pas conseillé alors? Et pourquoi donc dans ce cas?
Merci d'avance.

[Clorish]

C'est pas que le multi heritage soit foncierement deconseiller .....

C'est surtout que le monoheritage n'est pas plus restrictif dans un certains sens par rapport au multiheritage.
Disons que si ton objet est bien pensé, et que sa hierarchie a ete developpé correctement, on ne devrais que tres tres tres rarement faire appel au multiheritage.

On retrouve dans cette philosophie de gestion des classe l'eternel conflit entre Pascal et C : Pascal prefere refuser le multiheritage pour "securiser" les programmes en poussant les developpeurs programmer "proprement" et donc bien souvent se passer de ce multiheritage.
C quand a lui suppose que le programmeur "sait" programmer, et "sait" ce qu'il fait, donc donne la possibiliter de creer des classes multiparentales, pour ne pas bloquer le developpeur qui dans certains cas tres tres precis en aurais besoin.
Par contre aucune limite n'etant fixé, le developpeur debuttant verra en cette technique une aubaine : Plus besoin de passer 3h a reflechir sur la sous arborescence future de sa classe car il pourra toujours "rattrapper" le coup ....

"Bien des problemes de conceptions viennent du mauvais choix de l'ancetre. sous C++ les developpeur peu precautionneux s'en sorten in extremis grace au multiheritage qui permet de fusionner, apres coup, les avantages de plusieurs lignées dans une arborescence de classes. Avec delphi, qui comme java, n'implemente pas le multiheritage (sauf au niveau des interfaces), cette solution (aux resultat douteux) n'est pas disponible : Il faut donc penser convenablement l'heritage avant de commencer a ecrire le code c'un composnant (ou d'une classe en general)" - Extrait du livre de O.Dahan et P.Toth : Delphi 7 Studio -

D'ou les multiples classes delphi .....

Maintenant comme dit plus haut, plusieurs methodes sont possible pour programmer plus ou moins proprement une classe multiheritee
Exemple 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Type 
  TClassMultiHerit  = Class(TObject)
  Private
    FMaclasse1 : TMaclasse1;
    FMaclasse2 : TMaclasse2;
  Public
    Procedure MethodeDeMaclasse1;
    Procedure MethodeDeMaclasse2;
  End;
 
Procedure TClassMultiHerit.MethodeDeMaclasse1;
Begin
Self.FMaclasse1.MethodeDeMaclasse1;
End;
 
Procedure TClassMultiHerit.MEthodeDeMaclasse2;
Begin
Self.FMAclasse2.MethdodeDeMaclasse2;
End;

;

Ou bien en creant une interface qui definie toutes les nouvelles fonctions d'un objet.
ainsi, si on souhaite multiheriter, on peut declarer la nouvelle classe comem implementant 2 Interfaces. Le resultat sera le meme mais un "redeveloppement" des methodes sera necessaire.

Quoi qu'il en soit les techniques type "bidouilles" permettant de gerer le multiheritage sous Delphi semblerais etre aussi "bidouille" que le multiheritage sous C++ ... mais au moins elles ne sont pas cautionnées par les developpeurs du language

[SchpatziBreizh]

Ca sent le vécu tout ça … Merci pour les conseils, je vais alors revoir mon analyse avant de programmer. Pour donner mon avis, je trouve simplement que si l’analyse est bien faite, le multi-héritage donne une programmation propre et structurée et montre une certaine maturité par rapport à l’étude d’un projet, maintenant, je ne m’avancerais pas plus du fait de ma faible expérience dans le domaine.
Encore merci.

PS : Si tu as lu (et retenu) les 795 pages (hors annexes et index) du livre Delphi7 Studio de O.Dahan et P.Toth … Chapeau bas !

[Clorish]

Ca sent le vécu tout ça …

Du tout enfin .. j'ai quand meme eu une une overdose de "Segmentation Fault" dues au fait que le compilo C m'a laisser ecrire des truc barbares sous pretexte qu'il pensais que je savais ceque je faisait (le con !)

Pour donner mon avis, je trouve simplement que si l’analyse est bien faite, le multi-héritage donne une programmation propre et structurée et montre une certaine maturité par rapport à l’étude d’un projet, maintenant, je ne m’avancerais pas plus du fait de ma faible expérience dans le domaine.

Moi non plus je n'ai pas de tres grosses experiances ... enfin je developpe pleins d'objets, mais je n'ai pas connu le multi heritage.
Pour ma part son absence ne me gene pas et on peut tres bien s'en passer en faisant preuve d'un peut de rigueur dans la prog. Maintenant je ne dit pas que le multi heritage n'est pas pratique en soit mais malheureusement trop utilisé par des genses ne sachant pas ce qu'il font (et la ca met plsu de panique dans un projet que ca ne le structure a mon avis

ensuite je me base sur des avis de personnes plutot bien reputé dans le milieux :Ange:

PS : Si tu as lu (et retenu) les 795 pages (hors annexes et index) du livre Delphi7 Studio de O.Dahan et P.Toth … Chapeau bas ! Wink

Nan ! Du tout mais j'ai toujours un exemplaire du bouquin sous le bras

[cpdump]

Maintenant comme dit plus haut, plusieurs methodes sont possible pour programmer plus ou moins proprement une classe multiheritee
Exemple 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Type 
  TClassMultiHerit  = Class(TObject)
  Private
    FMaclasse1 : TMaclasse1;
    FMaclasse2 : TMaclasse2;
  Public
    Procedure MethodeDeMaclasse1;
    Procedure MethodeDeMaclasse2;
  End;
 
Procedure TClassMultiHerit.MethodeDeMaclasse1;
Begin
Self.FMaclasse1.MethodeDeMaclasse1;
End;
 
Procedure TClassMultiHerit.MEthodeDeMaclasse2;
Begin
Self.FMAclasse2.MethdodeDeMaclasse2;
End;

;

Ou bien en creant une interface qui definie toutes les nouvelles fonctions d'un objet.
ainsi, si on souhaite multiheriter, on peut declarer la nouvelle classe comem implementant 2 Interfaces. Le resultat sera le meme mais un "redeveloppement" des methodes sera necessaire.

Mettre deux objets dans une classe c'est de l'aggrégation, cela n'a rien à voir avec du multi héritage. La seule solution sous Delphi est de passer par les interfaces.

Quoi qu'il en soit les techniques type "bidouilles" permettant de gerer le multiheritage sous Delphi semblerais etre aussi "bidouille" que le multiheritage sous C++ ... mais au moins elles ne sont pas cautionnées par les developpeurs du language

Le multi héritage n'est pas une bidouille en C++, c'est un concept puissant à manier avec précaution et seulement quand c'est nécessaire.

[Clorish]

Le multi héritage n'est pas une bidouille en C++, c'est un concept puissant à manier avec précaution et seulement quand c'est nécessaire.

Ca je ne le remet pas en question
Mais un programmeur qui sait ce qu'il fait ... peut se servir comme il faut du multiheritage ou bien s'en passer.

Dans tout lesautres cas ca en reviens a de la bidouille .. pour retomber sur ses pates.

Quand a l'agregation .. possible j'ai jamais vu ce mot encore
Mais c'est un moyen qui permet de "simuler" le multi heritage ... a l'exception pres que les tests de derivation de classes seront faux .....