Benefits of using an abstract classes vs. regular class

Question

I have decided to start doing small coding projects on my own that focus on code quality instead of code quantity and have a question about the use of abstract classes.

Now I know the differences between abstract classes and interfaces with the biggest one (I think) being that interface allow you to only define methods that need to be implemented by classes using the interface and abstract classes allowing you to define both method and members along with default method implementation if you so desire. My question is what the the main benefit of use an abstract class vs a normal class? The only real difference between the two that I can think of is that you can not create an instance of an abstract class. Are there any other differences between the two?

Answer 1

Abstract classes can be used to store methods in an OOP-based "library"; since the class doesn't need to be instantiated, and would make little sense for it to be, keeping common static methods inside of an abstract class is a common practice.

Answer 2

In addition to not being able to create instances of abstract classes, some languages may support having abstract methods in abstract classes - similar to interfaces, an abstract method will have to be implemented by the class inheriting from the abstract class.

The main benefit of abstract classes in my opinion is if there is some code that has to be shared between classes of the same type. Usually you could use an interface for this, but sometimes the functionality of such classes may overlap and you would end up with code duplication. In this case you can use an abstract class and just put the code there.

Answer 3

You can see an abstract class like a generalization of (possibly) a set of concrete classes that inherit from it. When you design a domain model you should start abstracting (i.e. generalizing) common features. This generalization lends to the design of the abstract classes of the model. You could also implement methods that are meant to manipulate or handle abstract types (which, at runtime, will be eventually instances of concrete derived classes). For instance, imagine you whant to program a UI. You could need the concept of Component (an abstract class representing some object in your UI, but not necessarily visible). Then you could derive from Component the abstract class Control, which represents any visible component of the UI. Finally you'll have the concrete classes Textbox, Button, and so on, all deriving from the Control abstract class. Your UI class could have members meant to hold the references to the various Controls and Components. It will have methods meant to organize the various Controls (without knowing their concrete type, and delegating each concrete class to handle specific behaviours invoking virtual methods). All-in-all, abstract classes with virtual methods and polimorphism make programming more similiar to human thinking, keeping thinkgs neat and avoiding repetitive coding. You could also read something about OOP SOLID principles (Single Responsibility, Open-closed, Liskov Substitution, Interface Segregation and Dependency Inversion), for instance here.

EDIT (+)

On the contrary, interfaces are meant to describe sets of public methods. Interfaces are sort of a contract that a class have to follow (i.e. the class implementing an interface guarantees that it has all the methods described in the interface). For instance, you could have an interface IPlayable, which states that classes implementing it have to declare the methods Play() and Stop(). Then you could implement this interface in a DVDPlayer class, an MP3Player class and so on... whitout beeing obliged to inherit from base classes. You could also implement more than an interface in a single class, where multiple inheritance from classes is rarer (for instance, you can't have multiple inheritance neither in Java, nor in C#).

Answer 4

Strictly from a design perspective, it is best to simplify things. I believe the best way to simplify things is to use a simple analogy. Let's use an analogy of birds...

Interface: use this when you want to enforce certain functions which need to be defined. e.g. IBird has a contract for ScreamLikeABird and Fly (interface functions). But you can get more specific and have an IOstrich that has a Run contract. You may also have an IHawk that has an Attack contract...etc.

Abstract: use this when you want to enforce base functions and have base properties. e.g. Avian could be a base class for birds which may have a function called LayEgg as well as propeties called Age, Species, NumberOfChicks...etc. These things don't/shouldn't change the behavior of a bird, since all birds lay eggs...etc. But not all birds sounds the same when it scream or flies the same way (some dont even fly)....etc.... hence they should be implemented via an interface(s).