2010-04-08 7 views
32

Est-il acceptable de dériver une classe abstraite d'une classe non abstraite ou y a-t-il un problème avec cette approche?Dériver la classe abstraite de la classe non abstraite

Here's un petit exemple:

public class Task { 
    // Some Members 
} 

public abstract class PeriodicalTask : Task { 
    // Represents a base class for task that has to be done periodicaly. 
    // Some additional Members 
} 

public class DailyTask : PeriodicalTask { 
    // Represents a Task that has to be done daily. 
    // Some additional Members 
} 

public class WeeklyTask : PeriodicalTask { 
    // Represents a Task that has to be done weekly. 
    // Some additional Members 
} 

Dans l'exemple ci-dessus, je ne veux pas faire le résumé de la tâche de la classe, parce que je veux instancier directement. PeriodicalTask ​​doit hériter de la fonctionnalité de Task et ajouter des membres supplémentaires, mais je ne veux pas l'instancier directement. Seule la classe dérivée de PeriodicalTask ​​doit être instanciée.

Répondre

49

Je ne vois rien de mal à cette approche.

Vous pourriez avoir un type de base qui peut être décrit concrètement. Maintenant, juste parce qu'un objet de ce type pourrait être classifié selon un sous-type, il ne s'ensuit pas que tous ces sous-types soient aussi concrets; ils peuvent à leur tour exiger une plus grande concrétisation, pour ainsi dire.

exemple réel:

Person - béton (non abstraite)
Sibling: Person - abstrait
Brother: Sibling - béton
Sister: Sibling - béton

+2

Exemple parfait Dan –

+0

Bon exemple donc accepté – Jehof

+0

Wow! Vraiment, bel exemple. – ManuelSchneid3r

0

L'utilisation de abstract n'est pas la bonne approche ici, utilisez un constructeur protégé ou interne, par exemple. Cela empêcherait les instances de PeriodicalTask ​​d'être créées directement, mais ses classes dérivées y auraient toujours accès.

+0

Pouvez-vous élaborer? Oui, un constructeur protégé/interne peut empêcher la création de 'PeriodicalTask'. Mais il faudrait aussi des méthodes/propriétés abstraites de 'Task' pour avoir des implémentations. –

+0

Peu importe ... J'ai raté cette tâche n'était pas abstraite. Les deux approches fonctionneraient tout aussi bien dans cette situation. Sinon, vous ne pouvez pas forcer quelqu'un à implémenter une méthode dans une classe dérivée. –

+0

@kprobst: Oui je peux le faire, mais ensuite je perds la possibilité de définir des membres abstraits, qui doivent être implémentés par des types dérivés. Les membres virtuels ne sont pas une option, parce que les types dérivés doivent définir comment ils fonctionnent – Jehof

17

Rien à redire.

Si vous regardez une grande hiérarchie comme WinForms, vous trouverez plusieurs couches de types abstraits. Les tâches MSBuild sont également un bon exemple (et plus pertinent).

12

Ce genre de t hing arrive tout le temps: Toutes les classes abstraites héritent de System.Object, une classe qui n'est pas abstract en elle-même.

new System.Object() est parfois utile pour le verrouillage, si vous n'avez rien d'autre autour, vous pouvez verrouiller.

+0

C'est un bon point. Ce fait m'a manqué, car l'héritage de System.Object ne doit pas être défini explicitement. – Jehof

Questions connexes