Voici mon problème: j'essaie de concevoir une bibliotheque de composant qui
ont des propriétés et des méthodes communes.Donc j'ai une classe de base:
public class ControleDeBase : System.Windows.Forms.UserControl
J'aimerais donc deriver tous mes controles de ControleDeBase . Cependant,
mes controles peuvent avoir un comportement de type bouton donc j'aimerais
aussi pouvoir dériver de la classe Button ou un comportement de type TextBox
dériver de la classe TextBox.......
D'ou ma question : comment implémenter un controle qui hérite à la fois de
ma classe ControleDeBase et d'une classe Button ou PictureBox ou TextBox
etc...sachant que l'héritage multiple n'est pas conseillé!!!
Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir avec Trollou, perso je pense que C# est une révolution (ils ont mis le temps mais le résultat est là!!!). Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu mon problème...). Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à réecrire le meme code dans tous les descendants !!! Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon controle a un comportement de type TextBox c'est pas trop compatible! Donc l'idéal serait d'hériter d'une classe de base qui possède tous les attributs et méthodes communes (donc écriture du code une seul fois) et hériter d'un controle commun de Windows mais ca c'est pas possible en C#. Donc cela veut il dire que les sociétés qui développent des bibliothèque de controles héritent directement de la classe Controle et implémente tout le reste????Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est pas élégant: Ma classe de base contient un membre de chaque type de controle commun et j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
Voilà un paliatif mais c'est vraiment tordu!
Qu'en pensez vous?
"Ambassadeur Kosh" a écrit :
et agressif avec ça...
Bonjour Messieurs,
Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir
avec Trollou, perso je pense que C# est une révolution (ils ont mis le temps
mais le résultat est là!!!).
Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me
satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu mon
problème...).
Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à
réecrire le meme code dans tous les descendants !!!
Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon
controle a un comportement de type TextBox c'est pas trop compatible!
Donc l'idéal serait d'hériter d'une classe de base qui possède tous les
attributs et méthodes communes (donc écriture du code une seul fois) et
hériter d'un controle commun de Windows mais ca c'est pas possible en C#.
Donc cela veut il dire que les sociétés qui développent des bibliothèque de
controles héritent directement de la classe Controle et implémente tout le
reste????Ce serait pas très rentable!
Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est
pas élégant:
Ma classe de base contient un membre de chaque type de controle commun et
j'instancie dans le descendant le controle concerné:
public class MaClasseDeBase
{
public Button m_Button=null;
public PictureBox m_pictureBox=null;
public TextBox m_TextBox=null;
}
public class DescendantTypeBouton:MaClasseDeBase
{
public DescendantTypeBouton()
{
m_Button=new Button();
etc....
}
Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir avec Trollou, perso je pense que C# est une révolution (ils ont mis le temps mais le résultat est là!!!). Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu mon problème...). Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à réecrire le meme code dans tous les descendants !!! Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon controle a un comportement de type TextBox c'est pas trop compatible! Donc l'idéal serait d'hériter d'une classe de base qui possède tous les attributs et méthodes communes (donc écriture du code une seul fois) et hériter d'un controle commun de Windows mais ca c'est pas possible en C#. Donc cela veut il dire que les sociétés qui développent des bibliothèque de controles héritent directement de la classe Controle et implémente tout le reste????Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est pas élégant: Ma classe de base contient un membre de chaque type de controle commun et j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
Voilà un paliatif mais c'est vraiment tordu!
Qu'en pensez vous?
"Ambassadeur Kosh" a écrit :
et agressif avec ça...
Ambassadeur Kosh
> Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir avec Trollou, perso je pense que C# est une révolution (ils ont mis le temps mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique. quand on a baigné dans le C++ et dans les premiers langages à Objet, c'est souvent une deformation qu'on attrape : faire de l'heritage d'implantation.
Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu mon problème...).
ben si justement. j'ai bien vu, et je te donne la solution qui implante l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du compte tu ecriras + de code en heritant qu'en utilisant. ça aussi, c'est un classique. avoir baginé dans la vision heritage multiple ça biaise la vision des choses. mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon controle a un comportement de type TextBox c'est pas trop compatible! Donc l'idéal serait d'hériter d'une classe de base qui possède tous les attributs et méthodes communes (donc écriture du code une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton approche heritage multiple, tu verras pas de quoi je te parle dans 99.99% des cas, l'approche heritage multiple, c'est le symptome d'un design et d'une conception bancale. et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est pas possible en C#. Donc cela veut il dire que les sociétés qui développent des bibliothèque de controles héritent directement de la classe Controle et implémente tout le reste????
chsai pas moi, elle doivent etre bien connes alors, ces sociétés pour bosser sous C#... nan serieux, tu t'es pas dit une seconde que ce changement d'approche pouvait etre benefique ?
Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est pas élégant: Ma classe de base contient un membre de chaque type de controle commun et j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement d'instance sans être obligé de tout recompiler. je dirais meme que ta classe de base pourait heriter de UserControl mais ça c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu! Qu'en pensez vous?
que c'est peut être justement à creuser.
> Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir
avec Trollou, perso je pense que C# est une révolution (ils ont mis le
temps
mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique. quand on a baigné
dans le C++ et dans les premiers langages à Objet, c'est souvent une
deformation qu'on attrape : faire de l'heritage d'implantation.
Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me
satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu
mon
problème...).
ben si justement. j'ai bien vu, et je te donne la solution qui implante
l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à
réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du compte tu ecriras + de
code en heritant qu'en utilisant.
ça aussi, c'est un classique. avoir baginé dans la vision heritage multiple
ça biaise la vision des choses.
mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon
controle a un comportement de type TextBox c'est pas trop compatible!
Donc l'idéal serait d'hériter d'une classe de base qui possède tous les
attributs et méthodes communes (donc écriture du code une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton approche heritage
multiple, tu verras pas de quoi je te parle
dans 99.99% des cas, l'approche heritage multiple, c'est le symptome d'un
design et d'une conception bancale.
et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est pas possible en C#.
Donc cela veut il dire que les sociétés qui développent des bibliothèque
de
controles héritent directement de la classe Controle et implémente tout le
reste????
chsai pas moi, elle doivent etre bien connes alors, ces sociétés pour bosser
sous C#...
nan serieux, tu t'es pas dit une seconde que ce changement d'approche
pouvait etre benefique ?
Ce serait pas très rentable!
Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est
pas élégant:
Ma classe de base contient un membre de chaque type de controle commun et
j'instancie dans le descendant le controle concerné:
public class MaClasseDeBase
{
public Button m_Button=null;
public PictureBox m_pictureBox=null;
public TextBox m_TextBox=null;
}
public class DescendantTypeBouton:MaClasseDeBase
{
public DescendantTypeBouton()
{
m_Button=new Button();
etc....
}
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement d'instance sans être
obligé de tout recompiler.
je dirais meme que ta classe de base pourait heriter de UserControl mais ça
c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu!
Qu'en pensez vous?
> Je viens de lire ce matin vos réponses et je vous rassure j'ai rien à voir avec Trollou, perso je pense que C# est une révolution (ils ont mis le temps mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique. quand on a baigné dans le C++ et dans les premiers langages à Objet, c'est souvent une deformation qu'on attrape : faire de l'heritage d'implantation.
Donc pour revenir sur mon problème la solution d'Ambassadeur Kosh ne me satisfait pas (ce n'est pas une attaque mais je pense que tu n'as pas vu mon problème...).
ben si justement. j'ai bien vu, et je te donne la solution qui implante l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les interfaces qui m'obligent à réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du compte tu ecriras + de code en heritant qu'en utilisant. ça aussi, c'est un classique. avoir baginé dans la vision heritage multiple ça biaise la vision des choses. mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton exemple car si mon controle a un comportement de type TextBox c'est pas trop compatible! Donc l'idéal serait d'hériter d'une classe de base qui possède tous les attributs et méthodes communes (donc écriture du code une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton approche heritage multiple, tu verras pas de quoi je te parle dans 99.99% des cas, l'approche heritage multiple, c'est le symptome d'un design et d'une conception bancale. et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est pas possible en C#. Donc cela veut il dire que les sociétés qui développent des bibliothèque de controles héritent directement de la classe Controle et implémente tout le reste????
chsai pas moi, elle doivent etre bien connes alors, ces sociétés pour bosser sous C#... nan serieux, tu t'es pas dit une seconde que ce changement d'approche pouvait etre benefique ?
Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une solution mais c'est pas élégant: Ma classe de base contient un membre de chaque type de controle commun et j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement d'instance sans être obligé de tout recompiler. je dirais meme que ta classe de base pourait heriter de UserControl mais ça c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu! Qu'en pensez vous?
que c'est peut être justement à creuser.
Lamaison
Bonjour,
je sens derrière vos propos sur l'héritage des concepts qu'il parait intéressant d'approfondir. Cependant j'ai du mal avec le contenu du post ; auriez-vous un lien ( Français ) à me conseiller sur l'héritage "d'utilisation" etc. ?
Merci
-----Message d'origine-----
Je viens de lire ce matin vos réponses et je vous
rassure j'ai rien à voir
avec Trollou, perso je pense que C# est une révolution
(ils ont mis le
temps mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique.
quand on a baigné
dans le C++ et dans les premiers langages à Objet, c'est
souvent une
deformation qu'on attrape : faire de l'heritage
d'implantation.
Donc pour revenir sur mon problème la solution
d'Ambassadeur Kosh ne me
satisfait pas (ce n'est pas une attaque mais je pense
que tu n'as pas vu
mon problème...).
ben si justement. j'ai bien vu, et je te donne la
solution qui implante
l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les
interfaces qui m'obligent à
réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du
compte tu ecriras + de
code en heritant qu'en utilisant. ça aussi, c'est un classique. avoir baginé dans la vision
heritage multiple
ça biaise la vision des choses. mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton
exemple car si mon
controle a un comportement de type TextBox c'est pas
trop compatible!
Donc l'idéal serait d'hériter d'une classe de base qui
possède tous les
attributs et méthodes communes (donc écriture du code
une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton
approche heritage
multiple, tu verras pas de quoi je te parle dans 99.99% des cas, l'approche heritage multiple, c'est
le symptome d'un
design et d'une conception bancale. et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est
pas possible en C#.
Donc cela veut il dire que les sociétés qui développent
des bibliothèque
de controles héritent directement de la classe Controle et
implémente tout le
reste????
chsai pas moi, elle doivent etre bien connes alors, ces
sociétés pour bosser
sous C#... nan serieux, tu t'es pas dit une seconde que ce
changement d'approche
pouvait etre benefique ?
Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une
solution mais c'est
pas élégant: Ma classe de base contient un membre de chaque type de
controle commun et
j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement
d'instance sans être
obligé de tout recompiler. je dirais meme que ta classe de base pourait heriter de
UserControl mais ça
c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu! Qu'en pensez vous?
que c'est peut être justement à creuser.
.
Bonjour,
je sens derrière vos propos sur l'héritage
des concepts qu'il parait intéressant d'approfondir.
Cependant j'ai du mal avec le contenu du post ; auriez-vous
un lien ( Français ) à me conseiller sur
l'héritage "d'utilisation" etc. ?
Merci
-----Message d'origine-----
Je viens de lire ce matin vos réponses et je vous
rassure j'ai rien à voir
avec Trollou, perso je pense que C# est une révolution
(ils ont mis le
temps
mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique.
quand on a baigné
dans le C++ et dans les premiers langages à Objet, c'est
souvent une
deformation qu'on attrape : faire de l'heritage
d'implantation.
Donc pour revenir sur mon problème la solution
d'Ambassadeur Kosh ne me
satisfait pas (ce n'est pas une attaque mais je pense
que tu n'as pas vu
mon
problème...).
ben si justement. j'ai bien vu, et je te donne la
solution qui implante
l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les
interfaces qui m'obligent à
réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du
compte tu ecriras + de
code en heritant qu'en utilisant.
ça aussi, c'est un classique. avoir baginé dans la vision
heritage multiple
ça biaise la vision des choses.
mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton
exemple car si mon
controle a un comportement de type TextBox c'est pas
trop compatible!
Donc l'idéal serait d'hériter d'une classe de base qui
possède tous les
attributs et méthodes communes (donc écriture du code
une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton
approche heritage
multiple, tu verras pas de quoi je te parle
dans 99.99% des cas, l'approche heritage multiple, c'est
le symptome d'un
design et d'une conception bancale.
et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est
pas possible en C#.
Donc cela veut il dire que les sociétés qui développent
des bibliothèque
de
controles héritent directement de la classe Controle et
implémente tout le
reste????
chsai pas moi, elle doivent etre bien connes alors, ces
sociétés pour bosser
sous C#...
nan serieux, tu t'es pas dit une seconde que ce
changement d'approche
pouvait etre benefique ?
Ce serait pas très rentable!
Il doit exister un moyen mais lequel? J'ai pensé a une
solution mais c'est
pas élégant:
Ma classe de base contient un membre de chaque type de
controle commun et
j'instancie dans le descendant le controle concerné:
public class MaClasseDeBase
{
public Button m_Button=null;
public PictureBox m_pictureBox=null;
public TextBox m_TextBox=null;
}
public class DescendantTypeBouton:MaClasseDeBase
{
public DescendantTypeBouton()
{
m_Button=new Button();
etc....
}
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement
d'instance sans être
obligé de tout recompiler.
je dirais meme que ta classe de base pourait heriter de
UserControl mais ça
c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu!
Qu'en pensez vous?
je sens derrière vos propos sur l'héritage des concepts qu'il parait intéressant d'approfondir. Cependant j'ai du mal avec le contenu du post ; auriez-vous un lien ( Français ) à me conseiller sur l'héritage "d'utilisation" etc. ?
Merci
-----Message d'origine-----
Je viens de lire ce matin vos réponses et je vous
rassure j'ai rien à voir
avec Trollou, perso je pense que C# est une révolution
(ils ont mis le
temps mais le résultat est là!!!).
je sais. mais l'heritage multiple, c'est un classique.
quand on a baigné
dans le C++ et dans les premiers langages à Objet, c'est
souvent une
deformation qu'on attrape : faire de l'heritage
d'implantation.
Donc pour revenir sur mon problème la solution
d'Ambassadeur Kosh ne me
satisfait pas (ce n'est pas une attaque mais je pense
que tu n'as pas vu
mon problème...).
ben si justement. j'ai bien vu, et je te donne la
solution qui implante
l'equivalent de l'heritage multiple.
Ce que je veux c'est éviter de passer par les
interfaces qui m'obligent à
réecrire le meme code dans tous les descendants !!!
et moi je viens de te montrer par A + B qu'au bout du
compte tu ecriras + de
code en heritant qu'en utilisant. ça aussi, c'est un classique. avoir baginé dans la vision
heritage multiple
ça biaise la vision des choses. mais bon, laissons cela.
Aussi je ne peux pas hériter de Button comme dans ton
exemple car si mon
controle a un comportement de type TextBox c'est pas
trop compatible!
Donc l'idéal serait d'hériter d'une classe de base qui
possède tous les
attributs et méthodes communes (donc écriture du code
une seul fois)
non, l'idéal c'est de l'utiliser. si tu restes sur ton
approche heritage
multiple, tu verras pas de quoi je te parle dans 99.99% des cas, l'approche heritage multiple, c'est
le symptome d'un
design et d'une conception bancale. et c'est soutenu et validé.
hériter d'un controle commun de Windows mais ca c'est
pas possible en C#.
Donc cela veut il dire que les sociétés qui développent
des bibliothèque
de controles héritent directement de la classe Controle et
implémente tout le
reste????
chsai pas moi, elle doivent etre bien connes alors, ces
sociétés pour bosser
sous C#... nan serieux, tu t'es pas dit une seconde que ce
changement d'approche
pouvait etre benefique ?
Ce serait pas très rentable! Il doit exister un moyen mais lequel? J'ai pensé a une
solution mais c'est
pas élégant: Ma classe de base contient un membre de chaque type de
controle commun et
j'instancie dans le descendant le controle concerné: public class MaClasseDeBase { public Button m_Button=null; public PictureBox m_pictureBox=null; public TextBox m_TextBox=null; } public class DescendantTypeBouton:MaClasseDeBase { public DescendantTypeBouton() { m_Button=new Button(); etc.... }
}
tiens, de l'utilisation :o)
et maintenant, ton TextBox peut changer dynamiquement
d'instance sans être
obligé de tout recompiler. je dirais meme que ta classe de base pourait heriter de
UserControl mais ça
c'est toi qui voit si tu veux du design ou pas
Voilà un paliatif mais c'est vraiment tordu! Qu'en pensez vous?
que c'est peut être justement à creuser.
.
Ambassadeur Kosh
> je sens derrière vos propos sur l'héritage des concepts qu'il parait intéressant d'approfondir. Cependant j'ai du mal avec le contenu du post ; auriez-vous un lien ( Français ) à me conseiller sur l'héritage "d'utilisation" etc. ?
je crois que c'etait Arnaud qui nous avait proposé cet article l'an dernier à l'occasion de la conversation (explosive) sur le sujet.
sinon, un coup de google avec "heritage multiple critique" pour vous en convaincre.
pour la petite histoire, j'ai travaillé pendant pres de 5 ans dans une société qui utilise systematiquement l'heritage simple et multiple à mauvais escient. j'ai pu redevelopper un moteur d'optimisation entierement en C# offrant les meme fonctionalités. non seulement j'arrive à des performances bien superieures, mais le frein à la réutilisation (le couplage), à disparu. ceci m'a permis de specialiser certaines classes, d'en generaliser d'autres, d'introduire des "formalismes" d'ordre superieur, et d'offrir des fonctionalités beaucoup plus riches, et de faire effondrer la complexité du calcul. ceci sans avoir recours une seule fois à du bricolage d'implantation pour gagner des cycles.
il y'a 10 ans, je n'aurais jamais eu une telle approche. je bossais en C++ et j'étais convaincu de ce que je faisais.
voila voila
> je sens derrière vos propos sur l'héritage
des concepts qu'il parait intéressant d'approfondir.
Cependant j'ai du mal avec le contenu du post ; auriez-vous
un lien ( Français ) à me conseiller sur
l'héritage "d'utilisation" etc. ?
je crois que c'etait Arnaud qui nous avait proposé cet article l'an dernier
à l'occasion de la conversation (explosive) sur le sujet.
sinon, un coup de google avec "heritage multiple critique" pour vous en
convaincre.
pour la petite histoire, j'ai travaillé pendant pres de 5 ans dans une
société qui utilise systematiquement l'heritage simple et multiple à mauvais
escient. j'ai pu redevelopper un moteur d'optimisation entierement en C#
offrant les meme fonctionalités. non seulement j'arrive à des performances
bien superieures, mais le frein à la réutilisation (le couplage), à disparu.
ceci m'a permis de specialiser certaines classes, d'en generaliser d'autres,
d'introduire des "formalismes" d'ordre superieur, et d'offrir des
fonctionalités beaucoup plus riches, et de faire effondrer la complexité du
calcul. ceci sans avoir recours une seule fois à du bricolage d'implantation
pour gagner des cycles.
il y'a 10 ans, je n'aurais jamais eu une telle approche. je bossais en C++
et j'étais convaincu de ce que je faisais.
> je sens derrière vos propos sur l'héritage des concepts qu'il parait intéressant d'approfondir. Cependant j'ai du mal avec le contenu du post ; auriez-vous un lien ( Français ) à me conseiller sur l'héritage "d'utilisation" etc. ?
je crois que c'etait Arnaud qui nous avait proposé cet article l'an dernier à l'occasion de la conversation (explosive) sur le sujet.
sinon, un coup de google avec "heritage multiple critique" pour vous en convaincre.
pour la petite histoire, j'ai travaillé pendant pres de 5 ans dans une société qui utilise systematiquement l'heritage simple et multiple à mauvais escient. j'ai pu redevelopper un moteur d'optimisation entierement en C# offrant les meme fonctionalités. non seulement j'arrive à des performances bien superieures, mais le frein à la réutilisation (le couplage), à disparu. ceci m'a permis de specialiser certaines classes, d'en generaliser d'autres, d'introduire des "formalismes" d'ordre superieur, et d'offrir des fonctionalités beaucoup plus riches, et de faire effondrer la complexité du calcul. ceci sans avoir recours une seule fois à du bricolage d'implantation pour gagner des cycles.
il y'a 10 ans, je n'aurais jamais eu une telle approche. je bossais en C++ et j'étais convaincu de ce que je faisais.
