Quand et pourquoi utiliser des classes / méthodes abstraites?
J'ai quelques questions de base sur les classes/méthodes abstraites. Je sais que l'utilisation de base des classes abstraites est de créer des modèles pour les classes futures. Mais y a-t-il d'autres utilisations? Quand devriez-vous les préférer aux interfaces et quand non? Aussi, quand les méthodes abstraites sont-elles utiles?
Je sais que l'utilisation de base des classes abstraites consiste à créer des modèles pour les futures classes. Mais y a-t-il d'autres utilisations?
Non seulement vous pouvez définir un modèle pour les enfants, mais les classes abstraites offrent l'avantage supplémentaire de vous permettre de définir des fonctionnalités que vos classes enfants pourront utiliser ultérieurement.
Vous ne pouvez pas fournir d'implémentation pour une interface.
Quand devriez-vous les préférer aux interfaces et quand non?
Les classes abstraites sont un bon choix si vous voulez fournir des détails d'implémentation à vos enfants mais ne voulez pas permettre à une instance de votre classe d'être instanciée directement (ce qui vous permet de définir partiellement une classe).
Si vous souhaitez simplement définir un contrat pour les objets à suivre, utilisez une interface.
Aussi, quand les méthodes abstraites sont-elles utiles?
Les méthodes abstraites sont utiles de la même manière que la définition de méthodes dans une interface est utile. C'est une façon pour le concepteur de la classe Abstract de dire "n'importe quel de mes enfants DOIT implémenter cette méthode".
lire l'article suivant http://mycodelines.wordpress.com/2009/09/01/in-which-scenario-we-use-abstract-classes-and-interfaces/
Classes abstraites
-> Lorsque vous avez une exigence où votre classe de base doit fournir l'implémentation par défaut de certaines méthodes alors que d'autres méthodes devraient être ouvertes pour être remplacées par les classes enfants, utilisez des classes abstraites.
Par exemple reprenons l'exemple de la classe Véhicule ci-dessus. Si nous voulons que toutes les classes dérivées de Vehicle implémentent la méthode Drive () de manière fixe alors que les autres méthodes peuvent être remplacées par des classes enfants. Dans un tel scénario, nous implémentons la classe Vehicle en tant que classe abstraite avec une implémentation de Drive tout en laissant les autres méthodes/propriétés abstraites afin qu'elles puissent être remplacées par les classes enfants.
-> Le but d'une classe abstraite est de fournir une définition commune d'une classe de base que plusieurs classes dérivées peuvent partager.
Par exemple, une bibliothèque de classes peut définir une classe abstraite qui est utilisée comme paramètre pour bon nombre de ses fonctions et exiger que les programmeurs utilisant cette bibliothèque fournissent leur propre implémentation de la classe en créant une classe dérivée.
Utilisez une classe abstraite
Lors de la création d'une bibliothèque de classes qui sera largement distribuée ou réutilisée, en particulier pour les clients, utilisez une classe abstraite de préférence à une interface; car, cela simplifie la gestion des versions. C'est la pratique utilisée par l'équipe Microsoft qui a développé la bibliothèque de classes de base. (COM a été conçu autour des interfaces.) Utilisez une classe abstraite pour définir une classe de base commune pour une famille de types. Utilisez une classe abstraite pour fournir un comportement par défaut. Sous-classe uniquement une classe de base dans une hiérarchie à laquelle la classe appartient logiquement.
À un niveau très élevé:
L'abstraction, quelle qu'elle soit, revient à séparer les préoccupations. Le code "client" d'une abstraction ne se soucie pas de la manière dont le contrat exposé par l'abstraction est exécuté. Vous ne vous souciez généralement pas si une classe de chaîne utilise une implémentation de stockage interne à terminaison nulle ou à longueur de tampon, par exemple. L'encapsulation masque les détails, mais en créant des classes/méthodes/etc. abstrait, vous autorisez la modification de l'implémentation ou l'ajout de nouvelles implémentations sans affecter le code client.
Généralement, on utilise une classe abstraite pour fournir des fonctionnalités incomplètes qui seront étoffées par des sous-classes concrètes. Il peut fournir des méthodes utilisées par ses sous-classes; il peut également représenter un nœud intermédiaire dans la hiérarchie des classes, pour représenter un groupe commun de sous-classes concrètes, en les distinguant d'une certaine manière des autres sous-classes de sa superclasse. Puisqu'une interface ne peut pas dériver d'une classe, c'est une autre situation où une classe (abstraite ou autre) serait nécessaire, contre une interface.
Une bonne règle de base est que seuls les nœuds terminaux d'une hiérarchie de classes doivent être instanciés. Rendre les nœuds non-feuilles abstraits est un moyen facile de garantir cela.
Les classes/méthodes abstraites sont généralement utilisées lorsqu'une classe fournit des fonctionnalités de haut niveau mais laisse de côté certains détails à implémenter par les classes dérivées. Rendre la classe/méthode abstraite garantit qu'elle ne peut pas être utilisée seule, mais doit être spécialisée pour définir les détails qui ont été omis de l'implémentation de haut niveau. Ceci est le plus souvent utilisé avec le modèle de méthode de modèle: