Derive abstract class from non-abstract class

Question

Is it OK to derive an abstract class from a non-abstract class or is there something wrong with this approach?

Here´s a little example:

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 } 

In the example above I do not want to make the class Task abstract, because I want to instantiate it directly. PeriodicalTask should inherit the functionality from Task and add some additional members but I do not want to instantiate it directly. Only derived class of PeriodicalTask should be instantiated.

Answer 1

I don't see anything wrong with this approach.

You might have some basic type that can be described in concrete terms. Now, just because an object of this type might be further classified according to some subtype, it does not follow that all such subtypes are just as concrete; they may in turn require further concretization, as it were.

Real-world example:

Person -- concrete (non-abstract)
Sibling: Person -- abstract
Brother: Sibling -- concrete
Sister: Sibling -- concrete

Answer 2

Nothing wrong with it.

If you look at a big hierarchy like WinForms, you will find several layers of abstract types.

MSBuild tasks are also a good (and more relevant) example.