Member-only story
When to Use Abstract Classes
Abstract classes are overused and misused. But they have a few valid purposes

Abstract classes are a core feature of many object-oriented languages, such as Java.
Perhaps, for that reason, they tend to be overused and misused. Indeed, discussions abound about the overuse of inheritance in OO languages, and inheritance is core to using abstract classes.
In this article, we’ll use some examples of patterns and anti-patterns to illustrate when to use abstract methods, and when not to.
While this article presents the topic from a Java perspective, it is also relevant to most other object-oriented languages, even those without the concept of abstract classes.
To that end, let’s quickly define abstract classes. If you already know what abstract classes are, feel free to skip the following section.
Defining Abstract Classes
Technically speaking, an abstract class is a class that cannot be directly instantiated. Instead, it is designed to be extended by concrete classes that can be instantiated.
Abstract classes can — and typically do — define one or more abstract methods, that themselves do not contain a body. Instead, concrete subclasses are required to implement the abstract methods.
Let’s fabricate a quick example:
public abstract class Base { public void doSomething() {
System.out.println("Doing something...")
} public abstract void doSomethingElse();}
Note that doSomething()
, a non-abstract method, has implemented a body, while doSomethingElse()
, an abstract method, has not. You cannot directly instantiate an instance of Base
. Try this, and your compiler will complain:
Base b = new Base();
Instead, you need to subclass Base
like so:
public class Sub extends Base { public abstract void doSomethingElse() {
System.out.println("Doin' something else!");
}}