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
Merci à Boris et à tout le monde J'ai tout enregistré notamment sur les interfaces Merci
"Boris Sargos" a écrit dans le message de news: dmdefr$7t8$
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à.
Merci à Boris et à tout le monde
J'ai tout enregistré notamment sur les interfaces
Merci
"Boris Sargos" <bs@neuf.fr> a écrit dans le message de news:
dmdefr$7t8$1@apollon.grec.isp.9tel.net...
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.
Merci à Boris et à tout le monde J'ai tout enregistré notamment sur les interfaces Merci
"Boris Sargos" a écrit dans le message de news: dmdefr$7t8$
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à.
Titeuf
Excuse moi, Alors quand une classe hérite d'une interface on doit redéfinir les méthodes de l'interface dans la classe?
"Boris Sargos" a écrit dans le message de news: dmdefr$7t8$
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à.
Excuse moi,
Alors quand une classe hérite d'une interface on doit redéfinir les méthodes
de l'interface dans la classe?
"Boris Sargos" <bs@neuf.fr> a écrit dans le message de news:
dmdefr$7t8$1@apollon.grec.isp.9tel.net...
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.
Excuse moi, Alors quand une classe hérite d'une interface on doit redéfinir les méthodes de l'interface dans la classe?
"Boris Sargos" a écrit dans le message de news: dmdefr$7t8$
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à.
Ambassadeur Kosh
> Excuse moi, Alors quand une classe hérite d'une interface on doit redéfinir les méthodes de l'interface dans la classe?
oui. jamais de code ni de variables membres dans une interface. et c'est ce principe qui apporte enormement... donc tu dois redefinir dans l'heritiere, quitte à dire que la fonction de l'interface est abstract, mais tu declare ce que tu fais de toute façon.
public abstract class Test : object, ITest1 , ITest2 { // celle la, je la defini public void f() { } // celle la, je la rend abstract volontairement (c'est pas la conséquence d'un oubli ou d'un ajout par qq'un dans l'interface) public abstract void g() ;
// celle la, je la "recouvre" public int ITest2.h(int n) { return h(n) ; } public int h(int n) { return n+1 ; }
// celle la, elle est commune aux deux. public void z() { } }
en gros, tous ceux qui vont recevoir un objet designé comme Test verrons int h(int). à l'interieur de test, h designera aussi int h(int). par contre, celui qui verra un ITest2 aura dans sa ligne de mire un h(double).
hope this help
> Excuse moi,
Alors quand une classe hérite d'une interface on doit redéfinir les
méthodes de l'interface dans la classe?
oui. jamais de code ni de variables membres dans une interface. et c'est ce
principe qui apporte enormement...
donc tu dois redefinir dans l'heritiere, quitte à dire que la fonction de
l'interface est abstract, mais tu declare ce que tu fais de toute façon.
public abstract class Test : object, ITest1 , ITest2
{
// celle la, je la defini
public void f() { }
// celle la, je la rend abstract volontairement (c'est pas la
conséquence d'un oubli ou d'un ajout par qq'un dans l'interface)
public abstract void g() ;
// celle la, je la "recouvre"
public int ITest2.h(int n) { return h(n) ; }
public int h(int n) { return n+1 ; }
// celle la, elle est commune aux deux.
public void z() { }
}
en gros, tous ceux qui vont recevoir un objet designé comme Test verrons int
h(int). à l'interieur de test, h designera aussi int h(int).
par contre, celui qui verra un ITest2 aura dans sa ligne de mire un
h(double).
> Excuse moi, Alors quand une classe hérite d'une interface on doit redéfinir les méthodes de l'interface dans la classe?
oui. jamais de code ni de variables membres dans une interface. et c'est ce principe qui apporte enormement... donc tu dois redefinir dans l'heritiere, quitte à dire que la fonction de l'interface est abstract, mais tu declare ce que tu fais de toute façon.
public abstract class Test : object, ITest1 , ITest2 { // celle la, je la defini public void f() { } // celle la, je la rend abstract volontairement (c'est pas la conséquence d'un oubli ou d'un ajout par qq'un dans l'interface) public abstract void g() ;
// celle la, je la "recouvre" public int ITest2.h(int n) { return h(n) ; } public int h(int n) { return n+1 ; }
// celle la, elle est commune aux deux. public void z() { } }
en gros, tous ceux qui vont recevoir un objet designé comme Test verrons int h(int). à l'interieur de test, h designera aussi int h(int). par contre, celui qui verra un ITest2 aura dans sa ligne de mire un h(double).
hope this help
Titeuf
Merci merci...... c'est plus clair avec un exemple :)
Merci merci......
c'est plus clair avec un exemple :)
