'abstract class' versus 'normal class' for a reusable library

Question

I'm developing a reusable library and have been creating abstract classes, so the client can then extend from these.

QUESTION: Is there any reason in fact I should use an abstract class here as opposed to just a normal class?

Note - Have already decided I do not want to use interfaces as I want to include actual default methods in my library so the client using it doesn't have to write the code.

EDIT: So I'm fishing for any advantages I can't think of. For example when upgrading the library would use of an abstract class lessen impact on client code - I can't see it would in this case no?

Answer 1

The difference between an abstract class and a non-abstract one is that you can't instantiate the former and it MUST be overriden. It is really up to you to determine whether or not an instance of the base class makes sense on its own.

Let me show you two cases. One is where abstract class makes sense and one where it doesn't.

public abstract class Animal {
  public string Name {get;set;}
}

public class Dog : Animal {
  public Bark(){}
}

public class Cat : Animal {
  public Meaow(){}
}

In this scenario we have a common base Animal that provides implementation for Name property. It makes no sense to instantiate Animal by itself as there are no animals in the world that are just animals, they are wither dogs or cats or something else.

Here is a case where it makes sense to have a non-abstract base.

class Path {
  public Path(IList<Point> points) {
    this.Points = new ReadOnlyCollection<Point>(points);
  }
  public ReadOnlyCollection<Point> Points {get;}
}

class RectanglePath : Path{
  public SquarePath (Point origin, int height, int width) : 
   base(new List<Point>{origin, new Point(origin.X + width, point.Y}, ....){

  }
}

Here Path that is not subclassed makes sense, we can create any arbitrary shape, but it might be more convenient to use a sublass for more specific shapes.

Answer 2

Unless you want to force the end users to inherit from your classes, there should be no reason to use abstract.

If you want to make your classes inheritable and easily extensible, use virtual on your methods and make sure you have usable protected constructors.

Answer 3

Sounds like you are a little confused about the difference between a virtual method and an abstract class. You don't need to mark your class as abstract unless you determine that it doesn't make sense on it's own. This is useful in areas where you might have shared behaviors between multiple classes.

Sounds to me like you just need a regular class and some methods that are virtual.

Answer 4

The motivation for the abstract class is to require clients to override the class. Your decision on whether the class should be abstract or not depends primarily on whether the abstract is missing some fundamental behavior that only an user of the class can supply.

You can usually tell you need your class to be abstract if you use a template method of some sort, where "plug in the hole in this behavior" completes the logic of he class. If your class is useful without some user-supplied logic, you probably don't need the class to be abstract.

As an example, frameworks usually can't make decisions on behalf of their users in terms of things like object state validation, printing, display, and so on, and they would need to defer to concrete implementations by the clients.