Classes abstraites, Interfaces et Classes sealed

Le
Christian Hubert-Hugoud / weabow - Xtrem7
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
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Marc Thivolle
Le #20366821
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" 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
Le #20366911
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



Gloops
Le #20366901
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
Le #20367011
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" 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
Le #20367001
Merci à toi.

"Marc Thivolle" 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" 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
Le #20367081
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" 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" 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.
Publicité
Poster une réponse
Anonyme