Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu
pratiqués en VB6), autant je m'interroge pour savoir quand il est
intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela
me semble être très haut en concept et il me semble aussi, peut-être que je
me trompe, que c'est très bien adapté à de grosses applis, avec une analyse
très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Thivolle
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de grosses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins
d'implémentation à postériori. Je ne sais plus quelle structure a été
inventée avant l'autre. Utiliser les unes ou les autres c'est question de
goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" <nospam@weabow.com> a écrit dans
le message de news:euV9YHxTKHA.3412@TK2MSFTNGP06.phx.gbl...
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu
pratiqués en VB6), autant je m'interroge pour savoir quand il est
intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela
me semble être très haut en concept et il me semble aussi, peut-être que
je me trompe, que c'est très bien adapté à de grosses applis, avec une
analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de grosses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Gloops
Bonjour,
ça peut être pratique, si on a un certain nombre de véhicules à implémenter (ce n'est vraisemblablement l'exemple le plus en phase avec l'urgence écologique du moment mais l'avantage est qu'il "parle" bien).
Chacun va avoir à avancer, s'arrêter, tourner, reculer. Mais sur un tracteur on va engager un levier dans un sens, sur une voiture on va enclencher une vitesse avec le levier de vitesse au tableau de bord, sur une autre il va être au sol. La direction va se gérer avec un volant sur pas mal de véhicules, pas sur pelle mécani que.
Une fois qu'ont été définies toutes les propriétés et actions à gérer, il ne reste plus que les implémentations à mettre en place, et si on s'apprête à fournir un tracteur où on ne sait pas démarrer le mot eur, le compilateur va dire eh oh le bon dieu, là, y a maldonne dans ta palette . ça évitera de s'arracher les cheveux après à se demander pourquoi cet imbécile reste là à vous regarder sans bouger. Surtout, ça permet tra d'appeler plus facilement les différents véhicules depuis un autre programme qui saura les piloter, parce qu'on aura une fonction Tourner(cote, angle) qui sera commune à toutes les implémentations, m ême si les actions gérées en interne sur chaque sont différentes, que s ur un certain nombre on aura TournerVolant(cote, angle), mais que sur la pelle mécanique on aura ActionnerManetteCote(cote, angle), et que sur celle-c i on va repérer quelle est la deuxième manette et calculer les actions respectives sur les deux manettes. Eh bien l'avantage de la classe abstraite, c'est que ces deux fonctions portent obligatoirement le même nom, sans risque de faute de frappe.
C'est vrai que ça induit la nécessité d'une certaine capacité d'abstraction, mais de toute façon si c'est ça le point d'achoppement et que ça ne se voit pas on finit tôt ou tard par buter quelque part.
C'était déjà plus dur avec la programmation événementielle de f aire de la programmation "spaghetti" avec des goto vers des endroits bizarres qui n'ont rien à voir avec un début de séquence défini comme tel, mais avec la classe abstraite on va plus loin dans cette démarche et on a un outil qui encourage à faire du travail propre.
Alors une classe abstraite ne peut pas être implémentée comme telle . Qu'est-ce que ça signifie ? Que si tu arrives dans une concession et qu e tu déclares "Je veux acheter un véhicule", la première question que va te poser le vendeur est "Quel type de véhicule ?"
Mais ça n'empêche qu'il sait déjà que tu veux quelque chose qui s oit capable de démarrer, d'avancer, de reculer, de tourner ... Une fois que tu préciseras le type de véhicule, il saura comment tu vas t'y prendr e pour chacune de ces actions.
________________________________________________________________________ Christian Hubert-Hugoud / weabow - Xtrem7 a écrit, le 17/10/2009 12:08 :
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de gro sses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Bonjour,
ça peut être pratique, si on a un certain nombre de véhicules à
implémenter (ce n'est vraisemblablement l'exemple le plus en phase avec
l'urgence écologique du moment mais l'avantage est qu'il "parle" bien).
Chacun va avoir à avancer, s'arrêter, tourner, reculer.
Mais sur un tracteur on va engager un levier dans un sens, sur une
voiture on va enclencher une vitesse avec le levier de vitesse au
tableau de bord, sur une autre il va être au sol. La direction va se
gérer avec un volant sur pas mal de véhicules, pas sur pelle mécani que.
Une fois qu'ont été définies toutes les propriétés et actions à gérer,
il ne reste plus que les implémentations à mettre en place, et si on
s'apprête à fournir un tracteur où on ne sait pas démarrer le mot eur, le
compilateur va dire eh oh le bon dieu, là, y a maldonne dans ta palette .
ça évitera de s'arracher les cheveux après à se demander pourquoi cet
imbécile reste là à vous regarder sans bouger. Surtout, ça permet tra
d'appeler plus facilement les différents véhicules depuis un autre
programme qui saura les piloter, parce qu'on aura une fonction
Tourner(cote, angle) qui sera commune à toutes les implémentations, m ême
si les actions gérées en interne sur chaque sont différentes, que s ur un
certain nombre on aura TournerVolant(cote, angle), mais que sur la pelle
mécanique on aura ActionnerManetteCote(cote, angle), et que sur celle-c i
on va repérer quelle est la deuxième manette et calculer les actions
respectives sur les deux manettes. Eh bien l'avantage de la classe
abstraite, c'est que ces deux fonctions portent obligatoirement le même
nom, sans risque de faute de frappe.
C'est vrai que ça induit la nécessité d'une certaine capacité
d'abstraction, mais de toute façon si c'est ça le point d'achoppement et
que ça ne se voit pas on finit tôt ou tard par buter quelque part.
C'était déjà plus dur avec la programmation événementielle de f aire de
la programmation "spaghetti" avec des goto vers des endroits bizarres
qui n'ont rien à voir avec un début de séquence défini comme tel, mais
avec la classe abstraite on va plus loin dans cette démarche et on a un
outil qui encourage à faire du travail propre.
Alors une classe abstraite ne peut pas être implémentée comme telle .
Qu'est-ce que ça signifie ? Que si tu arrives dans une concession et qu e
tu déclares "Je veux acheter un véhicule", la première question que va
te poser le vendeur est "Quel type de véhicule ?"
Mais ça n'empêche qu'il sait déjà que tu veux quelque chose qui s oit
capable de démarrer, d'avancer, de reculer, de tourner ... Une fois que
tu préciseras le type de véhicule, il saura comment tu vas t'y prendr e
pour chacune de ces actions.
________________________________________________________________________
Christian Hubert-Hugoud / weabow - Xtrem7 a écrit, le 17/10/2009 12:08 :
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu
pratiqués en VB6), autant je m'interroge pour savoir quand il est
intéressant de mettre en oeuvre des classes abstraites et des sealed.
Cela me semble être très haut en concept et il me semble aussi,
peut-être que je me trompe, que c'est très bien adapté à de gro sses
applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
ça peut être pratique, si on a un certain nombre de véhicules à implémenter (ce n'est vraisemblablement l'exemple le plus en phase avec l'urgence écologique du moment mais l'avantage est qu'il "parle" bien).
Chacun va avoir à avancer, s'arrêter, tourner, reculer. Mais sur un tracteur on va engager un levier dans un sens, sur une voiture on va enclencher une vitesse avec le levier de vitesse au tableau de bord, sur une autre il va être au sol. La direction va se gérer avec un volant sur pas mal de véhicules, pas sur pelle mécani que.
Une fois qu'ont été définies toutes les propriétés et actions à gérer, il ne reste plus que les implémentations à mettre en place, et si on s'apprête à fournir un tracteur où on ne sait pas démarrer le mot eur, le compilateur va dire eh oh le bon dieu, là, y a maldonne dans ta palette . ça évitera de s'arracher les cheveux après à se demander pourquoi cet imbécile reste là à vous regarder sans bouger. Surtout, ça permet tra d'appeler plus facilement les différents véhicules depuis un autre programme qui saura les piloter, parce qu'on aura une fonction Tourner(cote, angle) qui sera commune à toutes les implémentations, m ême si les actions gérées en interne sur chaque sont différentes, que s ur un certain nombre on aura TournerVolant(cote, angle), mais que sur la pelle mécanique on aura ActionnerManetteCote(cote, angle), et que sur celle-c i on va repérer quelle est la deuxième manette et calculer les actions respectives sur les deux manettes. Eh bien l'avantage de la classe abstraite, c'est que ces deux fonctions portent obligatoirement le même nom, sans risque de faute de frappe.
C'est vrai que ça induit la nécessité d'une certaine capacité d'abstraction, mais de toute façon si c'est ça le point d'achoppement et que ça ne se voit pas on finit tôt ou tard par buter quelque part.
C'était déjà plus dur avec la programmation événementielle de f aire de la programmation "spaghetti" avec des goto vers des endroits bizarres qui n'ont rien à voir avec un début de séquence défini comme tel, mais avec la classe abstraite on va plus loin dans cette démarche et on a un outil qui encourage à faire du travail propre.
Alors une classe abstraite ne peut pas être implémentée comme telle . Qu'est-ce que ça signifie ? Que si tu arrives dans une concession et qu e tu déclares "Je veux acheter un véhicule", la première question que va te poser le vendeur est "Quel type de véhicule ?"
Mais ça n'empêche qu'il sait déjà que tu veux quelque chose qui s oit capable de démarrer, d'avancer, de reculer, de tourner ... Une fois que tu préciseras le type de véhicule, il saura comment tu vas t'y prendr e pour chacune de ces actions.
________________________________________________________________________ Christian Hubert-Hugoud / weabow - Xtrem7 a écrit, le 17/10/2009 12:08 :
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de gro sses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Gloops
Argh, après avoir passé un peu de temps à taper une réponse, ça fait un drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fou rni une autre réponse qui colle plus à la question et qui est plus sobre et plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoin s d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est questio n de goûts et de couleurs.
Bon week-end.
Marc
Argh, après avoir passé un peu de temps à taper une réponse, ça fait un
drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fou rni
une autre réponse qui colle plus à la question et qui est plus sobre et
plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoin s
d'implémentation à postériori. Je ne sais plus quelle structure a été
inventée avant l'autre. Utiliser les unes ou les autres c'est questio n
de goûts et de couleurs.
Argh, après avoir passé un peu de temps à taper une réponse, ça fait un drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fou rni une autre réponse qui colle plus à la question et qui est plus sobre et plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoin s d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est questio n de goûts et de couleurs.
Bon week-end.
Marc
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Merci pour ta réponse longuement développée.
Ce que j'en retire est que l'investissement est rentable et que tu encourages à aller dans ce sens.
Je te remercie de ta disponibilité.
"Gloops" a écrit dans le message de news: Argh, après avoir passé un peu de temps à taper une réponse, ça fait un drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fourni une autre réponse qui colle plus à la question et qui est plus sobre et plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
Merci pour ta réponse longuement développée.
Ce que j'en retire est que l'investissement est rentable et que tu
encourages à aller dans ce sens.
Je te remercie de ta disponibilité.
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de
news:ewRRxoxTKHA.3720@TK2MSFTNGP02.phx.gbl...
Argh, après avoir passé un peu de temps à taper une réponse, ça fait un
drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fourni
une autre réponse qui colle plus à la question et qui est plus sobre et
plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins
d'implémentation à postériori. Je ne sais plus quelle structure a été
inventée avant l'autre. Utiliser les unes ou les autres c'est question de
goûts et de couleurs.
Ce que j'en retire est que l'investissement est rentable et que tu encourages à aller dans ce sens.
Je te remercie de ta disponibilité.
"Gloops" a écrit dans le message de news: Argh, après avoir passé un peu de temps à taper une réponse, ça fait un drôle d'effet de s'apercevoir que pendant ce temps-là quelqu'un a fourni une autre réponse qui colle plus à la question et qui est plus sobre et plus exacte ...
Marc Thivolle a écrit, le 17/10/2009 12:48 :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Merci à toi.
"Marc Thivolle" a écrit dans le message de news:
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de grosses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Merci à toi.
"Marc Thivolle" <marc.nospam.lse@orange.fr> a écrit dans le message de
news:utUkydxTKHA.764@TK2MSFTNGP02.phx.gbl...
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins
d'implémentation à postériori. Je ne sais plus quelle structure a été
inventée avant l'autre. Utiliser les unes ou les autres c'est question de
goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" <nospam@weabow.com> a écrit
dans le message de news:euV9YHxTKHA.3412@TK2MSFTNGP06.phx.gbl...
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu
pratiqués en VB6), autant je m'interroge pour savoir quand il est
intéressant de mettre en oeuvre des classes abstraites et des sealed.
Cela me semble être très haut en concept et il me semble aussi, peut-être
que je me trompe, que c'est très bien adapté à de grosses applis, avec
une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Bon week-end.
Marc
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
Bonjour à tous,
Je découvre peu à peu C# et le Framework, et ses possibilités.
Autant je comprends l'intérêt immédiat des Interfaces (je les ai un peu pratiqués en VB6), autant je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed. Cela me semble être très haut en concept et il me semble aussi, peut-être que je me trompe, que c'est très bien adapté à de grosses applis, avec une analyse très poussée et très fine.
Mais peut-être aussi que quelque chose m'échappe ?
Votre point de vue m'intéresse.
Christian
Christophe Lephay
Tout d'abord, Marc, je te conseille de répondre plutôt en fin de message, car ça simplifie grandement les réponses...
"Marc Thivolle" a écrit dans le message de groupe de discussion :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Les classes abstraites sont antérieures aux interfaces.
Les interfaces présentent deux avantages. N'ayant pas de membres, elles simplifient les problématiques liées à l'héritage multiple (dont, en particulier, l'héritage en diamant), et permettent d'éviter d'alourdir le langage sur le plan syntaxique. Egalement, elles sont plus adaptées pour l'exécution de code distribué.
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed.
L'intérêt principal d'une classe abstraite est qu'elle permet aussi de fournir un contrat d'implémentation, par exemple le déclenchement d'events avant et après l'exécution d'une méthode protected surchargée (ou définie) dans les classes dérivées.
Concernant sealed, c'est un peu comme le fait de définir une méthode comme étant virtuelle ou non. C'est un choix de conception, qu'on décide au cas par cas. Le plus souvent, c'est pour restreindre l'utilisation d'une hiérarchie de classe a fortiori, sans qu'on l'ait prévu dès la conception, et sans qu'on puisse la refactorer après coup.
Tout d'abord, Marc, je te conseille de répondre plutôt en fin de message,
car ça simplifie grandement les réponses...
"Marc Thivolle" <marc.nospam.lse@orange.fr> a écrit dans le message de
groupe de discussion : utUkydxTKHA.764@TK2MSFTNGP02.phx.gbl...
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins
d'implémentation à postériori. Je ne sais plus quelle structure a été
inventée avant l'autre. Utiliser les unes ou les autres c'est question de
goûts et de couleurs.
Les classes abstraites sont antérieures aux interfaces.
Les interfaces présentent deux avantages. N'ayant pas de membres, elles
simplifient les problématiques liées à l'héritage multiple (dont, en
particulier, l'héritage en diamant), et permettent d'éviter d'alourdir le
langage sur le plan syntaxique. Egalement, elles sont plus adaptées pour
l'exécution de code distribué.
"Christian Hubert-Hugoud / weabow - Xtrem7" <nospam@weabow.com> a écrit
dans le message de news:euV9YHxTKHA.3412@TK2MSFTNGP06.phx.gbl...
je m'interroge pour savoir quand il est intéressant de mettre en oeuvre
des classes abstraites et des sealed.
L'intérêt principal d'une classe abstraite est qu'elle permet aussi de
fournir un contrat d'implémentation, par exemple le déclenchement d'events
avant et après l'exécution d'une méthode protected surchargée (ou définie)
dans les classes dérivées.
Concernant sealed, c'est un peu comme le fait de définir une méthode comme
étant virtuelle ou non. C'est un choix de conception, qu'on décide au cas
par cas. Le plus souvent, c'est pour restreindre l'utilisation d'une
hiérarchie de classe a fortiori, sans qu'on l'ait prévu dès la conception,
et sans qu'on puisse la refactorer après coup.
Tout d'abord, Marc, je te conseille de répondre plutôt en fin de message, car ça simplifie grandement les réponses...
"Marc Thivolle" a écrit dans le message de groupe de discussion :
Bonjour,
Les classes abstraites et les interfaces répondent aux mêmes besoins d'implémentation à postériori. Je ne sais plus quelle structure a été inventée avant l'autre. Utiliser les unes ou les autres c'est question de goûts et de couleurs.
Les classes abstraites sont antérieures aux interfaces.
Les interfaces présentent deux avantages. N'ayant pas de membres, elles simplifient les problématiques liées à l'héritage multiple (dont, en particulier, l'héritage en diamant), et permettent d'éviter d'alourdir le langage sur le plan syntaxique. Egalement, elles sont plus adaptées pour l'exécution de code distribué.
"Christian Hubert-Hugoud / weabow - Xtrem7" a écrit dans le message de news:
je m'interroge pour savoir quand il est intéressant de mettre en oeuvre des classes abstraites et des sealed.
L'intérêt principal d'une classe abstraite est qu'elle permet aussi de fournir un contrat d'implémentation, par exemple le déclenchement d'events avant et après l'exécution d'une méthode protected surchargée (ou définie) dans les classes dérivées.
Concernant sealed, c'est un peu comme le fait de définir une méthode comme étant virtuelle ou non. C'est un choix de conception, qu'on décide au cas par cas. Le plus souvent, c'est pour restreindre l'utilisation d'une hiérarchie de classe a fortiori, sans qu'on l'ait prévu dès la conception, et sans qu'on puisse la refactorer après coup.
