Surcharge de méthode

Tu changes une propriété... Qui serait le contenu de message... Tu utilises
alors un controle seulement, et le click afficherait le contenu de la
propriété message. Dans ton cas c'est la seule solution. Pour surcharger une
méthode de ton controle1, tu devrais creer une nouvelle classe basée sur le
controle1.



"SL3News" <toto@tata.fr> wrote in message
news:OmmC34Q$HHA.5980@TK2MSFTNGP04.phx.gbl...

Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}

private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}

Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.

Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}

Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.

Merci d'avance pour vos contributions.

j'ai l'impression que vous partez dans une logique d'heritage pour faire ce
genre de choses... ça, c'etait bon il y'a 20 ans quand on avait rien
d'autre.


votre action, elle est pas à placer dans un UserControl, c'est le boulot du
delegate que vous "plusegallez".
donc quand vous posez votre control, vous faites myUserControl.Click +=
theMethod ;
ainsi, votre comportement par défaut n'est pas de la responsabilité du
control, mais bien de celui qui le cree...
si vraiment vous avez besoin de concentrer l'ajout du message par défaut sur
le click, faites vous un Builder ou un Helper qui va vous fournir un
controle pret à l'emplois.

mais, si toutefois vous cherchez vraiment à faire un truc par défaut au cas
ou il n'y a pas d'event utilisateur, ça ressemblerait à ça :

protected override OnClick()
{
if(Click!=null)
Click(this,EventArgs.Empty) ;
else
MessageBox.Show("Merci d'avoir cliqué sur le controle ...") ;
}


voila voila


"SL3News" <toto@tata.fr> a écrit dans le message de news:
OmmC34Q$HHA.5980@TK2MSFTNGP04.phx.gbl...

Bonjour,
J'ai créé un contrôle UserControl1 grace au code suivant :
public partial class UserControl1 : Button
{
public UserControl1()
{
InitializeComponent();
}

private void UserControl1_Click(object sender, EventArgs e)
{
MessageBox.Show("Merci d'avoir cliqué sur le controle
UserControl1");
}
}

Ce contrôle contient une méthode permettant d'afficher le message "Merci
d'avoir cliqué sur le controle UserControl1" lorsqu'on clique dessus.
Tout marche bien lorsque j'ajoute ce contrôle à mes formulaires et que je
clique sur le contrôle, le bon message s'affiche.

Je veux surcharger cette méthode dans un formulaire spécifique. Pour ce
faire je mets le code suivant attaché au clic sur ce contrôle dans mon
formulaire spécifique.
private void userControl11_Click(object sender, EventArgs e)
{
MessageBox.Show("Je veux surcharger le code du click sur ce
controle");
}

Malheureusement à l'exécution, il m'affiche d'abord le message de la
classe "Merci d'avoir cliqué sur le controle UserControl1" puis le message
de surcharge "Je veux surcharger le code du click sur ce controle".
Que dois-je faire pour afficher uniquement le message de surcharge "Je
veux surcharger le code du click sur ce controle" sans afficher le message
de la classe.

Merci d'avance pour vos contributions.

/_Jean BONBEUR_ a exposé/ :

j'ai l'impression que vous partez dans une logique d'heritage pour faire ce
genre de choses... ça, c'etait bon il y'a 20 ans quand on avait rien d'autre.

je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#

--
*/Teträm/*
http://www.tetram.org

"Humain du matin, petite faim. Humain du soir, pour bien recevoir" -
Proverbe Troll

Bonjour,

Faust wrote:

/_Jean BONBEUR_ a exposé/ :

j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.

je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#

Non. L'héritage d'implémentation qui a longtemps été une des mamelles de
l'OOP a montré ses limites en générant des relations statiques entre les
classes au moment de la compilation. Ce qui génère du couplage, problème que
l'on essaie d'éviter comme la peste.

Le polymorphisme basé sur l'héritage d'interfaces est bien plus souple et
permet de gérer de manière dynamique les relations entre classes, produisant
ainsi des designs beaucoup plus efficaces et faciles à maintenir.

Ce qui ne veut pas dire que l'héritage d'implémentation n'est pas utile mais
il doit être remis à sa place et descendu du piédestal sur lequel il a trop
longtemps été placé.

Cordialement.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

loin de moi l'idée d'encenser l'héritage d'implémentation... de même,
le polymorphisme par l'usage d'interface est loin d'être la solution
miracle: le polymorphisme d'interface sans l'héritage d'implémentation
n'a aucun intérêt

ils sont complémentaires, et l'héritage d'implémentation a encore de
beaux jours devant elle

/_Patrick Philippot_ a formulé ce dimanche/ :

Bonjour,

Faust wrote:

/_Jean BONBEUR_ a exposé/ :

j'ai l'impression que vous partez dans une logique d'heritage pour
faire ce genre de choses... ça, c'etait bon il y'a 20 ans quand on
avait rien d'autre.

je pense que votre formulation est maladroite.... l'héritage est plus
que jamais d'actualité dans ce qu'on appelle communément la
programmation orientée objet (POO) que propose C#

Non. L'héritage d'implémentation qui a longtemps été une des mamelles de
l'OOP a montré ses limites en générant des relations statiques entre les
classes au moment de la compilation. Ce qui génère du couplage, problème que
l'on essaie d'éviter comme la peste.

Le polymorphisme basé sur l'héritage d'interfaces est bien plus souple et
permet de gérer de manière dynamique les relations entre classes, produisant
ainsi des designs beaucoup plus efficaces et faciles à maintenir.

Ce qui ne veut pas dire que l'héritage d'implémentation n'est pas utile mais
il doit être remis à sa place et descendu du piédestal sur lequel il a trop
longtemps été placé.

Cordialement.

--
*/Teträm/*
http://www.tetram.org

"Entre le cerveau et la main, le médiateur doit être le coeur" - Fritz
Lang

> loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt

je ne vais pas vous vanter comme une évidence ce que patrick vient de mettre
en lumiere, c'est quelque chose que j'ai découvert avec .Net... un article
de Patrick Smacchia qui traite du sujet, et qui en traite bien :
http://www.dotnetguru.org/articles/dossiers/heritageimpl/FragileBaseClass.htm

désolé d'avoir trollé, c'etait pas mon but. on etait dans un cas de figure
qui tombait pile dans la marmitte, d'ou mon intervention...

/_Jean BONBEUR_ a exposé/ :

loin de moi l'idée d'encenser l'héritage d'implémentation... de même, le
polymorphisme par l'usage d'interface est loin d'être la solution miracle:
le polymorphisme d'interface sans l'héritage d'implémentation n'a aucun
intérêt

je ne vais pas vous vanter comme une évidence ce que patrick vient de mettre
en lumiere, c'est quelque chose que j'ai découvert avec .Net... un article de
Patrick Smacchia qui traite du sujet, et qui en traite bien :
http://www.dotnetguru.org/articles/dossiers/heritageimpl/FragileBaseClass.htm

désolé d'avoir trollé, c'etait pas mon but. on etait dans un cas de figure
qui tombait pile dans la marmitte, d'ou mon intervention...

j'intervenais juste pour dire qu'il faut se méfier des raccourcis
faciles. Je cite ce passage de ce très bon article:
"Néanmoins, le message véhiculé par cet article ne sera pas ‘Mort à
l’héritage d’implémentation’. Notez au passage que le Framework .NET
(tout comme le Framework Java d’ailleurs) utilise allégrement
l’héritage d’implémentation. En outre, de nombreuses implémentations
des design pattern Gof ne peuvent se passer de l’héritage
d’implémentation (Abstract Factory, Factory, Prototype, Adapter,
Bridge, Chain of responsability, Composite, Observer, Template Method,
Visitor…). Ces deux arguments montrent bien que OUI, lorsque l’on a
constaté que c’est la moins mauvaise des solutions, on doit utiliser
l’héritage d’implémentation. Ce n’est pas parce que je peux me couper
le doigt avec un couteau que je vais arrêter d’en utiliser ! J’apprend
plutôt à m’en servir correctement."

de plus, je ferais juste remarquer que la problématique soulevée en
début de l'article n'existe pas avec certains languages. Je pense
notamment à Delphi qui autorise le mot clé "class of" qui permet de
faire exactement ce qui est suggéré en solution et ce sans utiliser
d'interface. Et ça depuis au moins maintenant 10 ans (ce mot clé
existait déjà dans la version 3 de Delphi sortie, si je ne me trompe
pas en 1996)
Je ne dis pas que c'était THE solution, je dis juste que je faisais du
polymorphisme (d'interface ou non du coup puisque c'était avec Delphi)
bien avant l'arrivée de .Net, que les "limites de la POO" étaient
imposées par le language largement diffusé mais au combien loin d'être
d'être parfait (je pense ici au C++) et que mon expérience me permet de
dire que le polymorphisme d'interface (et les interfaces en général)
est loin d'être la réponse à tout.

enfin, pour illustrer la conclusion de l'article "Préférez la
composition d’objets à l’héritage d’implémentation.", je rappelerais
que le mot clé en Java pour dériver une classe est "extends" qui, de
tous les languages que je connais, porte le mieux son nom puisqu'on
dérive une classe pour étendre les fonctionnalités de la classe parent
et non pour en redéfinir complètement le fonctionnement (comme suggéré
en problématique de l'article). Elle est peut-être là la limité de la
POO: la compréhension des développeurs de ce vaste "concept".

--
*/Teträm/*
http://www.tetram.org

<Jables> Personnelement, c'est pas Dieu qui me dérange, c'est son
putain de fan club..
http://www.bashfr.org/?2544

bon, ben trollons alors :)

je repete que ça concernais son truc à lui, j'ai beau relire mon post, je ne
vois pas de mise à mort de l'heritage.

Java comme .Net 1.0 et Delphi à l'heure ou il n'y avait pas de genericité
proposaient par exemple une CollectionBase. on pouvait trés bien creer sa
classe MyList , heritiere d'object, de IEnumerable, et de IList, et
l'implanter explicitement au choix avec un ArrayList ou ce qu'on veut...
CollectionBase est un raccourci facile vers la mise en oeuvre d'une
ArrayList, mais en quoi est il vraiment avantageux ? les framework sont
gavés de ce genre d'exemple. mais il y'a certainement des cas ou ça doit
valoir le coup, encore faut il mettre en lumiere la valeur du truc.

en C++, on trouve istream, ostream, iostream, ifstream, ofstream etc etc...
en .Net, on a des Reader, des Writer, des Stream, c'est vachement plus
propre. le Stream se decline en MemoryStream, FileStream etc... et les
Writer sont typés en fonction de chaque besoin : Xml, Texte, binaire,
Crypto... si on ajoute un type de writer, il n'y aura pas besoin de le
decliner à toutes les sauces pour qu'il tienne compte de chaque type de
stream... à ma petite echelle, moi je vois ça comme une bonne chose...

j'intervenais juste pour dire qu'il faut se méfier des raccourcis faciles.

arf. faut peut etre un peu elever le debat la

En outre, de nombreuses implémentations des design pattern Gof ne peuvent
se passer de l'héritage d'implémentation (Abstract Factory, Factory,
Prototype, Adapter, Bridge, Chain of responsability, Composite, Observer,
Template Method, Visitor.).

sans les connaitre tous, c'est marrant, mais je ne vois pas d'heritage
d'implantation dans une factory... la encore, peut etre un rapport à la
genericité ? même topo que CollectionBase. pour les autres, entre ceux dont
on ne se sert jamais parcequ'on a d'autres mécanismes (je pense à Visitor et
Observer), et ceux qu'on ne connait tout simplement pas, eh ben, c'est
difficile de se faire un avi.

Ces deux arguments montrent bien que OUI, lorsque l'on a constaté que c'est
la moins mauvaise des solutions, on doit utiliser l'héritage d'implémentation.
Ce n'est pas parce que je peux me couper le doigt avec un couteau que je
vais arrêter d'en utiliser ! J'apprend plutôt à m'en servir correctement."

ben evidement, et dans son cas à lui, on commence vite par apprendre à
utiliser des delegate et des event. point.

de plus, je ferais juste remarquer que la problématique soulevée en début
de l'article n'existe pas avec certains languages. Je pense notamment à
Delphi qui autorise le mot clé "class of" qui permet de faire exactement
ce qui est suggéré en solution et ce sans utiliser d'interface. Et ça
depuis au moins maintenant 10 ans (ce mot clé existait déjà dans la
version 3 de Delphi sortie, si je ne me trompe pas en 1996)
Je ne dis pas que c'était THE solution, je dis juste que je faisais du
polymorphisme (d'interface ou non du coup puisque c'était avec Delphi)
bien avant l'arrivée de .Net, que les "limites de la POO" étaient imposées
par le language largement diffusé mais au combien loin d'être d'être
parfait (je pense ici au C++) et que mon expérience me permet de dire que
le polymorphisme d'interface (et les interfaces en général) est loin
d'être la réponse à tout.

arf, dans n'importe quel langage, on aurait pu faire ça. les Writer et les
Reader, on aurait pu les avoir en C++. les abstract class auraient pu
remplir à merveille le rôle d'interface. ça vient des gens et de leur
mentalité tout ça... je gratte deux cycles à la con parceque le compilateur
de chez machin genere un code legerement plus rapide que les autres... tout
une époque...

en problématique de l'article). Elle est peut-être là la limité de la POO:
la compréhension des développeurs de ce vaste "concept".

c'est clair ! parfaitement bien dit ! un bon joueur d'echec, sais deplacer
les pieces :)

fin du troll pour ma part.

"Jean BONBEUR" <jean.bonbeur@snak.bar> a écrit dans le message de news:
u2VjCln$HHA.5652@TK2MSFTNGP05.phx.gbl...

je repete que ça concernais son truc à lui, j'ai beau relire mon post, je
ne vois pas de mise à mort de l'heritage.

Ouais, enfin le lien que tu donnes parle tout de même de supprimer
l'héritage de classe pour ne garder que celui d'interface (en citant je sais
plus qui de java). Le reste de l'article a beau tenter de rester un peu
modéré, tout comme ton message, il n'en reste pas moins qu'il cite un
exemple à charge (un cas où l'héritage de classe pose problème) sans en
citer aucun à décharge (qui montre un cas où il est justifié).

Personnellement, j'ai trouvé l'article à la fois biaisé et dogmatique.

Java comme .Net 1.0 et Delphi à l'heure ou il n'y avait pas de genericité
proposaient par exemple une CollectionBase. on pouvait trés bien creer sa
classe MyList , heritiere d'object, de IEnumerable, et de IList, et
l'implanter explicitement au choix avec un ArrayList ou ce qu'on veut...
CollectionBase est un raccourci facile vers la mise en oeuvre d'une
ArrayList, mais en quoi est il vraiment avantageux ? les framework sont
gavés de ce genre d'exemple. mais il y'a certainement des cas ou ça doit
valoir le coup, encore faut il mettre en lumiere la valeur du truc.

L'arrayList fournit un service au programeur - ie gérer des tableaux sans
avoir à s'occuper de leur taille. Malgré son typage faible, il fait partie
des services minimum qu'on est en droit d'attendre d'un framework
(structures de données fondamentales). Le typage faible peut être un
problème si le tableau n'est pas encapsulé dans une classe qui s'occupe des
vérifications de type, mais c'est toujours mieux que rien.

en C++, on trouve istream, ostream, iostream, ifstream, ofstream etc
etc... en .Net, on a des Reader, des Writer, des Stream, c'est vachement
plus propre.
le Stream se decline en MemoryStream, FileStream etc... et les Writer sont
typés en fonction de chaque besoin : Xml, Texte, binaire, Crypto... si on
ajoute un type de writer, il n'y aura pas besoin de le decliner à toutes
les sauces pour qu'il tienne compte de chaque type de stream... à ma
petite echelle, moi je vois ça comme une bonne chose...

Je vois pas trop en quoi c'est "vachement plus propre", ni même différent.
Tu pourrais être plus explicite, stp ?

arf, dans n'importe quel langage, on aurait pu faire ça. les Writer et les
Reader, on aurait pu les avoir en C++.

Que font les Writers et tes Readers que les flux et leurs iterateurs en c++
ne font pas ?

les abstract class auraient pu remplir à merveille le rôle d'interface.

Pourquoi "auraient pu" ? Libre à toi de faire une interface en c++. La seule
différence, c'est que c'est le même mot clé (class ou struct). Je vois pas
bien où est le problème.

Il se trouve que l'héritage multiple peut parfois poser problème (avec les
hiérarchies "en diamant"), et que la problématique est grandement simplifiée
si on n'hérite pas d'attributs d'instances, mais si tu veux offrir en c++
les fonctionnalités d'une interface au sens java ou c#, rien ne t'empeche de
le faire, tandis que le contraire n'est pas possible (je pense, en
particulier, à l'impossibilité d'effectuer des pré ou postconditions dans
les interfaces en java ou c#).

ça vient des gens et de leur mentalité tout ça... je gratte deux cycles à
la con parceque le compilateur de chez machin genere un code legerement
plus rapide que les autres... tout une époque...

Je suis pas sur que tu connaisses la mentalité des programmeurs c++
contemporains, et encore moins celle du comité de normalisation.

Avoir du code efficace est un critère important, mais bien moins que la
*possibilité* d'avoir du code robuste.

Ce n'est pas pour rien que de plus en plus de fonctionnalités du c++ qui
avaient initialement été mises de coté, que ce soit dans java ou c#, sont
progressivement réintégrées à ces langages. Toutes vont dans le même sens :
un système de typage plus robuste.

en problématique de l'article). Elle est peut-être là la limité de la
POO: la compréhension des développeurs de ce vaste "concept".

c'est clair ! parfaitement bien dit ! un bon joueur d'echec, sais deplacer
les pieces :)

Ce qui limite avant tout la compréhension du programmeur, ce sont ses
dogmes. A force de vouloir absolument faire de l'OO, on finit parfois à le
faire en dépit du bon sens.

La programmation générique, par exemple, constitue un paradigme à part
entière qui n'a que peu à voir avec la POO. Si elle commence à être intégrée
dans des langages comme Java ou c#, c'est bien parce que, confronté aux
réalités pratiques, ces langages commencent à sortir du dogme du tout OO.