probleme de conception

15 réponses

devkool

29/09/2004 à 13:27

Bonjour à tous,

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é!!!

Merci pour votre aide

10 réponses

1 2

Bismark Prods

29/09/2004 à 14:24

Il n'est pas interdit de définir une interface commune.

"devkool" a écrit dans le message de
news:

Bonjour à tous,

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é!!!

Merci pour votre aide

devkool

29/09/2004 à 14:41

Est ce le seul moyen??

"Bismark Prods" a écrit :

Il n'est pas interdit de définir une interface commune.

"devkool" a écrit dans le message de
news:
> Bonjour à tous,
>
> 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é!!!
>
> Merci pour votre aide

devkool

29/09/2004 à 15:23

En plus l'inconvénient des interfaces c'est qu'il faudra implémenter le meme
code dans tous les descendants donc je ne vois pas l'interêt.

"devkool" a écrit :

Est ce le seul moyen??

"Bismark Prods" a écrit :

> Il n'est pas interdit de définir une interface commune.
>
> "devkool" a écrit dans le message de
> news:
> > Bonjour à tous,
> >
> > 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é!!!
> >
> > Merci pour votre aide
>
>
>

Bismark Prods

29/09/2004 à 16:37

L'intérêt c'est de pouvoir faire appel aux mêmes membres en étant sur que
ces derniers existes quelque soit le descendant !

Et puis il te reste le recourt à "abstract"

"devkool" a écrit dans le message de
news:

En plus l'inconvénient des interfaces c'est qu'il faudra implémenter le

meme

code dans tous les descendants donc je ne vois pas l'interêt.

"devkool" a écrit :

> Est ce le seul moyen??
>
> "Bismark Prods" a écrit :
>
> > Il n'est pas interdit de définir une interface commune.
> >
> > "devkool" a écrit dans le message

> > news:
> > > Bonjour à tous,
> > >
> > > 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é!!!
> > >
> > > Merci pour votre aide
> >
> >
> >

Ambassadeur Kosh

29/09/2004 à 19:18

aie aie aie.... trollou is back :o)

bon, pas d'heritage multiple de class. c'est de l'heritage d'implantation.
c'est une catastrophe

herite de button, et range dans ta classe un attribut de type
ControleDeBase, que tu instancie dans le constructeur. prepare une interface
IDeBase, qui enumere toutes les methodes que tu veux rendre "abstraites"
(c'est comme ça qu'on dit en culture C++), et fait "heriter" ControleDeBase
de IDeBase.
jusque la, c'est cucul.

ensuite, tu fais heriter ton controle descendant de Button de IDeBase.
(comme diraient eric et ramzy, ça fait deux fois marche). et dans chaque
methode à implanter, tu ecris

typeretour methodeN(type1 arg1,...)
{
return this.controledebase.methodeN(arg1,...) ;
}

chui d'accord que c'est moins rigolo que l'heritage multiple, mais tu verras
qu'à l'usage, l'heritage d'implantation est largement remplacée par de
l'utilisation.

exemple, les stream.

faire un XmlStream qui herite de Stream, c'est completement naze. mais
naivement, en C++, il y'a quelques années, ça aurait été frequent de trouver
ça. mais c'est une catastrophe.

en fait, tu as un XmlWriter qui prend un stream en parametre dans le
constructeur et qui l'utilise.
comme ça, le stream peut dériver son concept fort (MemoryStream,
FileStream...), et le Writer peut deriver son axe fort.

imagine que tu aies N derivées pour le Stream et M pour le Writer. par
heritage multiple, ça fait N + M + N * M classes à écrire. alors que la, ça
fait N+M classes. c'est un argument quantitatif, mais il montre justement
qu'il y'a quelque chose d'ordre quantitatif et que ça doit plutot se
resoudre par une valeur (un attribut) plutot que par un heritage.

j'espere ne pas avoir été trop lourd, et que ça t'as apporté quelque chose
ma foi...

Bismark Prods

29/09/2004 à 19:31

c'est quoi cette histoire *récurrente* de troullou ?

"Ambassadeur Kosh" a écrit dans le message de
news:

aie aie aie.... trollou is back :o)

bon, pas d'heritage multiple de class. c'est de l'heritage d'implantation.
c'est une catastrophe

herite de button, et range dans ta classe un attribut de type
ControleDeBase, que tu instancie dans le constructeur. prepare une

interface

IDeBase, qui enumere toutes les methodes que tu veux rendre "abstraites"
(c'est comme ça qu'on dit en culture C++), et fait "heriter"

ControleDeBase

de IDeBase.
jusque la, c'est cucul.

ensuite, tu fais heriter ton controle descendant de Button de IDeBase.
(comme diraient eric et ramzy, ça fait deux fois marche). et dans chaque
methode à implanter, tu ecris

typeretour methodeN(type1 arg1,...)
{
return this.controledebase.methodeN(arg1,...) ;
}

chui d'accord que c'est moins rigolo que l'heritage multiple, mais tu

verras

qu'à l'usage, l'heritage d'implantation est largement remplacée par de
l'utilisation.

exemple, les stream.

faire un XmlStream qui herite de Stream, c'est completement naze. mais
naivement, en C++, il y'a quelques années, ça aurait été frequent de

trouver

ça. mais c'est une catastrophe.

en fait, tu as un XmlWriter qui prend un stream en parametre dans le
constructeur et qui l'utilise.
comme ça, le stream peut dériver son concept fort (MemoryStream,
FileStream...), et le Writer peut deriver son axe fort.

imagine que tu aies N derivées pour le Stream et M pour le Writer. par
heritage multiple, ça fait N + M + N * M classes à écrire. alors que la,

ça

fait N+M classes. c'est un argument quantitatif, mais il montre justement
qu'il y'a quelque chose d'ordre quantitatif et que ça doit plutot se
resoudre par une valeur (un attribut) plutot que par un heritage.

j'espere ne pas avoir été trop lourd, et que ça t'as apporté quelque chose
ma foi...

Ambassadeur Kosh

29/09/2004 à 22:10

> c'est quoi cette histoire *récurrente* de troullou ?

trollou intervient rarement ici, beaucoup sur microsoft.public.forum.dotnet

trollou est une legende vivante.

trollou depuis quelques temps nous fait vivre des aventures fantastiques et
des debats d'idée passionants :o)

retrouvez les aventures de trollou sur microsoft.public.forum.dotnet, ou
procurez vous les deux films en VO : "trollou et l'heritage d'implantation,
la seule vraie voie du salut" , "trollou explique à Paul pourquoi C++ c'est
bien, et pourquoi Microsoft, c'est mal"

c'est du direct live 100% insultes, mauvaise foi, explosion des posts,
contradictions et hysterie.

voila voila

Bismark Prods

29/09/2004 à 22:46

En fait t'es son agent ? Tu fais sa promotion ?
C'est plutôt sympa ...

"Ambassadeur Kosh" a écrit dans le message de
news:%

> c'est quoi cette histoire *récurrente* de troullou ?

trollou intervient rarement ici, beaucoup sur

microsoft.public.forum.dotnet

trollou est une legende vivante.

trollou depuis quelques temps nous fait vivre des aventures fantastiques

des debats d'idée passionants :o)

retrouvez les aventures de trollou sur microsoft.public.forum.dotnet, ou
procurez vous les deux films en VO : "trollou et l'heritage

d'implantation,

la seule vraie voie du salut" , "trollou explique à Paul pourquoi C++

c'est

bien, et pourquoi Microsoft, c'est mal"

c'est du direct live 100% insultes, mauvaise foi, explosion des posts,
contradictions et hysterie.

voila voila

Ambassadeur Kosh

29/09/2004 à 23:28

> En fait t'es son agent ? Tu fais sa promotion ?

ouaih. c'est devenu mon Buisness. il fait le spectacle, moi j'organise, je
trouve les salles, le matos, je fourgue les billets aux fnacs et autres
points de vente, j'innonde les radios de spots publicitaires, je sous traite
la creation de produits derivés... Troll Agent, c'est un metier msieu
Bismark

C'est plutôt sympa ...

moi je rafolle, mais bon, ceux qui se font insulter, y ont des fois du
mal... c'est un peu le Maurice de Skyrock, mais version loose technik trés
décalé. tout le monde répond à trollou pour essayer de lui faire comprendre,
de l'aider, de le convaincre, de passer à l'antenne. et ça fait de
l'audimat.

satisfait de cette paranthese culturelle ?

Bismark Prods

30/09/2004 à 00:31

personnellement c'est toi qui commence à m'agacer ... avec ton "troll
detector" et "trollou"... Ca fait sans doute partie de ton monde, tu imagine
pas vivre sans en parler au moins 1 fois par jour. Mais moi ca me "saoule".

"Ambassadeur Kosh" a écrit dans le message de
news:

> En fait t'es son agent ? Tu fais sa promotion ?

ouaih. c'est devenu mon Buisness. il fait le spectacle, moi j'organise, je
trouve les salles, le matos, je fourgue les billets aux fnacs et autres
points de vente, j'innonde les radios de spots publicitaires, je sous

traite

la creation de produits derivés... Troll Agent, c'est un metier msieu
Bismark

> C'est plutôt sympa ...

moi je rafolle, mais bon, ceux qui se font insulter, y ont des fois du
mal... c'est un peu le Maurice de Skyrock, mais version loose technik trés
décalé. tout le monde répond à trollou pour essayer de lui faire

comprendre,

de l'aider, de le convaincre, de passer à l'antenne. et ça fait de
l'audimat.

satisfait de cette paranthese culturelle ?

1 2

probleme de conception

10 réponses

Veuillez sélectionner un problème