Bonjour,
Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ??
(J'utilise Vs2005)
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
Merci d'avance
Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005) Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ? Merci d'avance
Salut Titeuf,
C# 2.0 ne supporte pas l'héritage multiple, mais comme pour C# 1.0, tu
peux hériter de plusieurs interfaces.
Par contre tu peux utiliser les class partielles pour résoudre certain
pattern résolu par l'héritage multiple.
Bonjour,
Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++
??
(J'utilise Vs2005)
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
Merci d'avance
Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005) Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ? Merci d'avance
Titeuf
Merci pour ta réponse !
"Alexandre Roba" a écrit dans le message de news: 003b01c5f28f$6e98f410$
Salut Titeuf,
C# 2.0 ne supporte pas l'héritage multiple, mais comme pour C# 1.0, tu peux hériter de plusieurs interfaces.
Par contre tu peux utiliser les class partielles pour résoudre certain pattern résolu par l'héritage multiple.
Bien à toi,
Alexandre Roba
Merci pour ta réponse !
"Alexandre Roba" <no@reply.com> a écrit dans le message de news:
003b01c5f28f$6e98f410$0502a8c0@Internal.arobanet.be...
Salut Titeuf,
C# 2.0 ne supporte pas l'héritage multiple, mais comme pour C# 1.0, tu
peux hériter de plusieurs interfaces.
Par contre tu peux utiliser les class partielles pour résoudre certain
pattern résolu par l'héritage multiple.
"Alexandre Roba" a écrit dans le message de news: 003b01c5f28f$6e98f410$
Salut Titeuf,
C# 2.0 ne supporte pas l'héritage multiple, mais comme pour C# 1.0, tu peux hériter de plusieurs interfaces.
Par contre tu peux utiliser les class partielles pour résoudre certain pattern résolu par l'héritage multiple.
Bien à toi,
Alexandre Roba
Ambassadeur Kosh
> Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005)
"comme en C++"... l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces... donne un exemple précis et détaillé ou tu as besoin d'heritage multiple, et on va faire la version C#.
> Bonjour,
Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ??
(J'utilise Vs2005)
"comme en C++"...
l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces...
donne un exemple précis et détaillé ou tu as besoin d'heritage multiple, et
on va faire la version C#.
> Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005)
"comme en C++"... l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces... donne un exemple précis et détaillé ou tu as besoin d'heritage multiple, et on va faire la version C#.
Arnaud Debaene
Alexandre Roba wrote:
Par contre tu peux utiliser les class partielles pour résoudre certain pattern résolu par l'héritage multiple.
En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Arnaud MVP - VC
Alexandre Roba wrote:
Par contre tu peux utiliser les class partielles pour résoudre certain
pattern résolu par l'héritage multiple.
En quoi les classes partielles résolvent-elles l'absence d'héritage multiple
d'implémentation? Je ne vois pas trop le rapport...
Par contre tu peux utiliser les class partielles pour résoudre certain pattern résolu par l'héritage multiple.
En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Arnaud MVP - VC
Titeuf
Salut, En fait dans ma classe cIo.cs j'ai placés mes méthodes et mes propriétés pour traiter les fichiers et les dossiers.
bon j'ai dis comme en c++ car j'ai crus lire que cela était possible avec.
voici ma classe partielle ClIo (oui pas terrible le non je sais) cIo.cs -> méthodes et propriétés communes cFile.cs -> méthodes et propriétés pour les actions sur des fichiers cDirectory.cs - idem mais pour les actions sur les dossiers
je pense que je me suis mal exprimé car l'utilisation de classes partielles dans mon cas me convients car je voulais juste découpé ma classe pour bien distinguer mes différentes méthodes. les interface j'ai du mal à comprendre à quoi elles servent et dans quels cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
merci à vous
"Ambassadeur Kosh" a écrit dans le message de news:
Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005)
"comme en C++"... l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces... donne un exemple précis et détaillé ou tu as besoin d'heritage multiple, et on va faire la version C#.
Salut,
En fait dans ma classe cIo.cs j'ai placés mes méthodes et mes propriétés
pour traiter les fichiers et les dossiers.
bon j'ai dis comme en c++ car j'ai crus lire que cela était possible avec.
voici ma classe partielle ClIo (oui pas terrible le non je sais)
cIo.cs -> méthodes et propriétés communes
cFile.cs -> méthodes et propriétés pour les actions sur des fichiers
cDirectory.cs - idem mais pour les actions sur les dossiers
je pense que je me suis mal exprimé car l'utilisation de classes partielles
dans mon cas me convients car je voulais juste découpé ma classe pour bien
distinguer mes différentes méthodes.
les interface j'ai du mal à comprendre à quoi elles servent et dans quels
cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
merci à vous
"Ambassadeur Kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
news: eDMTdpr8FHA.3880@TK2MSFTNGP12.phx.gbl...
Bonjour,
Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ??
(J'utilise Vs2005)
"comme en C++"...
l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces...
donne un exemple précis et détaillé ou tu as besoin d'heritage multiple,
et on va faire la version C#.
Salut, En fait dans ma classe cIo.cs j'ai placés mes méthodes et mes propriétés pour traiter les fichiers et les dossiers.
bon j'ai dis comme en c++ car j'ai crus lire que cela était possible avec.
voici ma classe partielle ClIo (oui pas terrible le non je sais) cIo.cs -> méthodes et propriétés communes cFile.cs -> méthodes et propriétés pour les actions sur des fichiers cDirectory.cs - idem mais pour les actions sur les dossiers
je pense que je me suis mal exprimé car l'utilisation de classes partielles dans mon cas me convients car je voulais juste découpé ma classe pour bien distinguer mes différentes méthodes. les interface j'ai du mal à comprendre à quoi elles servent et dans quels cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
merci à vous
"Ambassadeur Kosh" a écrit dans le message de news:
Bonjour, Est-ce que C# 2.0 supporte l'héritage multiple de classes comme en c++ ?? (J'utilise Vs2005)
"comme en C++"... l'heritage multiple n'est pas une bonne habitude de façon générale.
Si non y a t-il un moyen à part d'hériter chaque classe d'une classe ?
l'utilisation, ou l'implantation d'interfaces... donne un exemple précis et détaillé ou tu as besoin d'heritage multiple, et on va faire la version C#.
Boris Sargos
Salut Titeuf,
si tu connais un peu les classes abstraites, une interface est une "super classe abstraite". Il s'agit donc d'une "classe" qui ne possède aucune donnée membre, mais uniquement des instructions destinées à ses classes filles : ce sont les méthodes (et propriétés). Ainsi, l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour des clients. Eux te fournissent une classe Matrice, et toi tu leur retournes les algorithmes. Beaucoup d'implémentations sont possibles pour une classe Matrice. Les données peuvent être stockées dans une collection, un tableau 2D, etc ... C'est le contexte qui fera choisir telle ou telle implémentation. Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir additionner deux matrices, les multiplier, ou en récupérer les éléments. Peu importe l'implémentation choisie par le client. Tu vas donc créer une interface IMatrice, qui sera la base de toute implémentation de classe Matrice. Cette interface aura comme méthode Addition, Multiplication et Element. Chaque client qui utilisera ta librairie devra créer une classe Matrice héritée de ton interface IMatrice. L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant ses propres contraintes, tant qu'il respecte les instructions Addition, Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure, qui ne contient aucune donnée membre. Mais comme en C# on a interdit l'héritage multiple de classes, il a fallu créer ce concept d'Interface qui est vraiment efficace.
Voilà.
Salut Titeuf,
si tu connais un peu les classes abstraites, une interface est une
"super classe abstraite". Il s'agit donc d'une "classe" qui ne possède
aucune donnée membre, mais uniquement des instructions destinées à ses
classes filles : ce sont les méthodes (et propriétés). Ainsi,
l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour
des clients. Eux te fournissent une classe Matrice, et toi tu leur
retournes les algorithmes.
Beaucoup d'implémentations sont possibles pour une classe Matrice. Les
données peuvent être stockées dans une collection, un tableau 2D, etc
... C'est le contexte qui fera choisir telle ou telle implémentation.
Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir
additionner deux matrices, les multiplier, ou en récupérer les éléments.
Peu importe l'implémentation choisie par le client. Tu vas donc créer
une interface IMatrice, qui sera la base de toute implémentation de
classe Matrice. Cette interface aura comme méthode Addition,
Multiplication et Element. Chaque client qui utilisera ta librairie
devra créer une classe Matrice héritée de ton interface IMatrice.
L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant
ses propres contraintes, tant qu'il respecte les instructions Addition,
Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure,
qui ne contient aucune donnée membre. Mais comme en C# on a interdit
l'héritage multiple de classes, il a fallu créer ce concept d'Interface
qui est vraiment efficace.
si tu connais un peu les classes abstraites, une interface est une "super classe abstraite". Il s'agit donc d'une "classe" qui ne possède aucune donnée membre, mais uniquement des instructions destinées à ses classes filles : ce sont les méthodes (et propriétés). Ainsi, l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour des clients. Eux te fournissent une classe Matrice, et toi tu leur retournes les algorithmes. Beaucoup d'implémentations sont possibles pour une classe Matrice. Les données peuvent être stockées dans une collection, un tableau 2D, etc ... C'est le contexte qui fera choisir telle ou telle implémentation. Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir additionner deux matrices, les multiplier, ou en récupérer les éléments. Peu importe l'implémentation choisie par le client. Tu vas donc créer une interface IMatrice, qui sera la base de toute implémentation de classe Matrice. Cette interface aura comme méthode Addition, Multiplication et Element. Chaque client qui utilisera ta librairie devra créer une classe Matrice héritée de ton interface IMatrice. L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant ses propres contraintes, tant qu'il respecte les instructions Addition, Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure, qui ne contient aucune donnée membre. Mais comme en C# on a interdit l'héritage multiple de classes, il a fallu créer ce concept d'Interface qui est vraiment efficace.
Voilà.
Boris Sargos
> En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non. Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout court. Avec un code propre. Je trouve ça pas mal.
> En quoi les classes partielles résolvent-elles l'absence d'héritage multiple
d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non.
Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout
court. Avec un code propre. Je trouve ça pas mal.
> En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non. Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout court. Avec un code propre. Je trouve ça pas mal.
Titeuf
Oui dans mon cas cela convient, je n'ai plus besoin d'héritage j'ai diviser en plusieurs fichiers ma classe pour mieux distinguer mes différentes catégories de méthodes
"Boris Sargos" a écrit dans le message de news: dmcal4$c2m$
En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non. Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout court. Avec un code propre. Je trouve ça pas mal.
Oui dans mon cas cela convient, je n'ai plus besoin d'héritage j'ai diviser
en plusieurs fichiers ma classe pour mieux distinguer mes différentes
catégories de méthodes
"Boris Sargos" <bs@neuf.fr> a écrit dans le message de news:
dmcal4$c2m$2@aphrodite.grec.isp.9tel.net...
En quoi les classes partielles résolvent-elles l'absence d'héritage
multiple d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non.
Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout
court. Avec un code propre. Je trouve ça pas mal.
Oui dans mon cas cela convient, je n'ai plus besoin d'héritage j'ai diviser en plusieurs fichiers ma classe pour mieux distinguer mes différentes catégories de méthodes
"Boris Sargos" a écrit dans le message de news: dmcal4$c2m$
En quoi les classes partielles résolvent-elles l'absence d'héritage multiple d'implémentation? Je ne vois pas trop le rapport...
Héritage multiple, non. Mais c'est vrai que ça permet dans certains cas d'éviter l'héritage tout court. Avec un code propre. Je trouve ça pas mal.
Ambassadeur Kosh
> je pense que je me suis mal exprimé car l'utilisation de classes partielles dans mon cas me convients car je voulais juste découpé ma classe pour bien distinguer mes différentes méthodes.
ok. partial class
les interface j'ai du mal à comprendre à quoi elles servent et dans quels cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
on va dire que c'est "une abstract class avec que des methodes virtuelles pures".
- idem hm C++, le polymorphisme, mais seulement heritage virtual. - laisse toujours à l'heritiere l'implantation.
côté pratique, regarde IDisposable, ICloneable, IList<T>...
> je pense que je me suis mal exprimé car l'utilisation de classes
partielles dans mon cas me convients car je voulais juste découpé ma
classe pour bien distinguer mes différentes méthodes.
ok. partial class
les interface j'ai du mal à comprendre à quoi elles servent et dans quels
cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
on va dire que c'est "une abstract class avec que des methodes virtuelles
pures".
- idem hm C++, le polymorphisme, mais seulement heritage virtual.
- laisse toujours à l'heritiere l'implantation.
côté pratique, regarde IDisposable, ICloneable, IList<T>...
> je pense que je me suis mal exprimé car l'utilisation de classes partielles dans mon cas me convients car je voulais juste découpé ma classe pour bien distinguer mes différentes méthodes.
ok. partial class
les interface j'ai du mal à comprendre à quoi elles servent et dans quels cas les utiliser !, si quelqu'un avais 2 minutes pour m'expliquer merci
on va dire que c'est "une abstract class avec que des methodes virtuelles pures".
- idem hm C++, le polymorphisme, mais seulement heritage virtual. - laisse toujours à l'heritiere l'implantation.
côté pratique, regarde IDisposable, ICloneable, IList<T>...
Boris Sargos
Salut Titeuf,
si tu connais un peu les classes abstraites, une interface est une "super classe abstraite". Il s'agit donc d'une "classe" qui ne possède aucune donnée membre, mais uniquement des instructions destinées à ses classes filles : ce sont les méthodes (et propriétés). Ainsi, l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour des clients. Eux te fournissent une classe Matrice, et toi tu leur retournes les algorithmes. Beaucoup d'implémentations sont possibles pour une classe Matrice. Les données peuvent être stockées dans une collection, un tableau 2D, etc ... C'est le contexte qui fera choisir telle ou telle implémentation. Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir additionner deux matrices, les multiplier, ou en récupérer les éléments. Peu importe l'implémentation choisie par le client. Tu vas donc créer une interface IMatrice, qui sera la base de toute implémentation de classe Matrice. Cette interface aura comme méthode Addition, Multiplication et Element. Chaque client qui utilisera ta librairie devra créer une classe Matrice héritée de ton interface IMatrice. L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant ses propres contraintes, tant qu'il respecte les instructions Addition, Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure, qui ne contient aucune donnée membre. Mais comme en C# on a interdit l'héritage multiple de classes, il a fallu créer ce concept d'Interface qui est vraiment efficace.
Voilà.
Salut Titeuf,
si tu connais un peu les classes abstraites, une interface est une
"super classe abstraite". Il s'agit donc d'une "classe" qui ne possède
aucune donnée membre, mais uniquement des instructions destinées à ses
classes filles : ce sont les méthodes (et propriétés). Ainsi,
l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour
des clients. Eux te fournissent une classe Matrice, et toi tu leur
retournes les algorithmes.
Beaucoup d'implémentations sont possibles pour une classe Matrice. Les
données peuvent être stockées dans une collection, un tableau 2D, etc
... C'est le contexte qui fera choisir telle ou telle implémentation.
Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir
additionner deux matrices, les multiplier, ou en récupérer les éléments.
Peu importe l'implémentation choisie par le client. Tu vas donc créer
une interface IMatrice, qui sera la base de toute implémentation de
classe Matrice. Cette interface aura comme méthode Addition,
Multiplication et Element. Chaque client qui utilisera ta librairie
devra créer une classe Matrice héritée de ton interface IMatrice.
L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant
ses propres contraintes, tant qu'il respecte les instructions Addition,
Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure,
qui ne contient aucune donnée membre. Mais comme en C# on a interdit
l'héritage multiple de classes, il a fallu créer ce concept d'Interface
qui est vraiment efficace.
si tu connais un peu les classes abstraites, une interface est une "super classe abstraite". Il s'agit donc d'une "classe" qui ne possède aucune donnée membre, mais uniquement des instructions destinées à ses classes filles : ce sont les méthodes (et propriétés). Ainsi, l'implémentation est totalement laissée aux héritiers.
Imagine que tu doives réaliser une bibliothèque d'algèbre linéaire pour des clients. Eux te fournissent une classe Matrice, et toi tu leur retournes les algorithmes. Beaucoup d'implémentations sont possibles pour une classe Matrice. Les données peuvent être stockées dans une collection, un tableau 2D, etc ... C'est le contexte qui fera choisir telle ou telle implémentation. Ce que tu souhaites toi, dans ta librairie, c'est simplement pouvoir additionner deux matrices, les multiplier, ou en récupérer les éléments. Peu importe l'implémentation choisie par le client. Tu vas donc créer une interface IMatrice, qui sera la base de toute implémentation de classe Matrice. Cette interface aura comme méthode Addition, Multiplication et Element. Chaque client qui utilisera ta librairie devra créer une classe Matrice héritée de ton interface IMatrice. L'avantage pour lui est qu'il l'implémente comme il le souhaite, suivant ses propres contraintes, tant qu'il respecte les instructions Addition, Multiplication et Element.
C'est clair ?
Donc en C++, l'équivalent d'une Interface est une classe virtuelle pure, qui ne contient aucune donnée membre. Mais comme en C# on a interdit l'héritage multiple de classes, il a fallu créer ce concept d'Interface qui est vraiment efficace.
