Abstract Classes - Learning Module

Loading content...

0/246

When to Use Abstract Classes

The Right Tool for the Right Problem

You now understand what abstract classes are and how abstract methods work. But understanding a tool is different from knowing when to use it. A hammer is well-understood, but that doesn't mean every fastening problem calls for a hammer.

Abstract classes are powerful, but they're not always the right choice. Sometimes interfaces are better. Sometimes concrete inheritance suffices. Sometimes composition beats inheritance entirely. The mark of a skilled designer is knowing which abstraction mechanism fits which situation.

This page establishes clear criteria for when abstract classes are the optimal design choice, and equally important, when they should be avoided.

What You Will Learn

By the end of this page, you will have a concrete decision framework for choosing abstract classes. You'll understand the specific scenarios that call for abstract classes, recognize the warning signs that suggest other approaches, and be able to defend your design decisions with clear reasoning.

The Core Decision Criteria

Abstract classes excel when you need both shared implementation and enforced customization within a true IS-A hierarchy. This is the sweet spot that no other mechanism serves as well.

Let's break down each criterion:

Abstract Classes Are Right When ALL Apply

•IS-A Relationship Exists — Subclasses are genuinely specialized versions of the abstract type. A Circle IS-A Shape. A PostgresConnection IS-A DatabaseConnection. The relationship is semantic, not just structural.
•Significant Shared Code — You have non-trivial implementation that all subtypes should inherit. This isn't just one line—it's substantial logic that would be duplicated across all implementations if not inherited.
•Required Customization Points — Some behaviors genuinely differ across subtypes and cannot have sensible defaults. These become abstract methods that the compiler enforces.
•Single Inheritance Is Acceptable — You can tolerate the constraint that classes can extend only one parent. If a class needs to fulfill multiple abstract contracts, interfaces may be better.
•State Is Shared — The abstract class needs to maintain instance variables that subclasses inherit. Pure interfaces cannot hold state (until default methods, which have limitations).

All five criteria should be met. If even one is missing, another mechanism might be more appropriate:

No IS-A relationship? → Consider composition
No shared code? → Consider interfaces
No required customization? → Consider concrete base class
Need multiple contracts? → Consider interfaces
No shared state? → Consider interfaces

The Inheritance Tax

Every abstract class imposes an "inheritance tax"—the cost of single inheritance slot usage. In Java/C#/TypeScript, a class can only extend one parent. Choose abstract classes only when this cost is worth the benefits.

Ideal Scenarios for Abstract Classes

Let's examine concrete scenarios where abstract classes shine:

Scenario 1: Framework Extension Points

•You're building a framework that users will extend
•You need to provide substantial helper functionality
•Certain methods MUST be implemented by users
•Examples: Web frameworks with BaseController, testing frameworks with TestCase, game engines with GameObject

FrameworkExtension
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// FRAMEWORK CODE: Abstract base provides infrastructure
public abstract class HttpServlet {
    
    // Framework provides HTTP parsing, session management, etc.
    private HttpRequest parseRequest(InputStream in) { /* complex */ return null; }
    private void sendResponse(HttpResponse response) { /* complex */ }
    protected HttpSession getSession() { return currentSession; }
    protected void log(String message) { /* logging infrastructure */ }
    
    // USERS MUST implement at least one of these
    protected abstract void doGet(HttpRequest req, HttpResponse resp);
    protected abstract void doPost(HttpRequest req, HttpResponse resp);
    
    // Template method - framework controls flow
    public final void service(InputStream in, OutputStream out) {
        HttpRequest request = parseRequest(in);
        HttpResponse response = new HttpResponse(out);
        
        try {
            switch (request.getMethod()) {
                case "GET":  doGet(request, response); break;
                case "POST": doPost(request, response); break;
            }
        } catch (Exception e) {
            log("Error: " + e.getMessage());
            response.sendError(500);
        }
        
        sendResponse(response);
    }
}
 
// USER CODE: Just implement the specific behavior
public class UserController extends HttpServlet {
    
    @Override
    protected void doGet(HttpRequest req, HttpResponse resp) {
        String userId = req.getParameter("id");
        User user = findUser(userId);
        resp.json(user);  // Uses inherited convenience method
    }
    
    @Override
    protected void doPost(HttpRequest req, HttpResponse resp) {
        User user = req.parseBody(User.class);
        saveUser(user);
        log("User saved: " + user.getId());  // Uses inherited logging
        resp.created();
    }
}

Scenario 2: Domain Hierarchies with Shared Logic

•You're modeling a real-world hierarchy (products, employees, documents)
•Entities share significant common behavior
•Certain calculations/behaviors vary by type
•Examples: Employee hierarchy (salary calculation varies), PaymentMethod (processing varies), Document (rendering varies)

DomainHierarchy
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
// Domain hierarchy with significant shared behavior
public abstract class Employee {
    protected String name;
    protected String employeeId;
    protected LocalDate hireDate;
    protected BigDecimal baseSalary;
    protected Department department;
    
    public Employee(String name, String employeeId, BigDecimal baseSalary) {
        this.name = name;
        this.employeeId = employeeId;
        this.hireDate = LocalDate.now();
        this.baseSalary = baseSalary;
    }
    
    // Shared behavior: tenure calculation
    public int getYearsOfService() {
        return Period.between(hireDate, LocalDate.now()).getYears();
    }
    
    // Shared behavior: base salary retrieval
    public BigDecimal getBaseSalary() {
        return baseSalary;
    }
    
    // Shared behavior: department management
    public void transferTo(Department newDept) {
        this.department = newDept;
        logTransfer(newDept);
    }
    
    // ABSTRACT: Compensation varies significantly by employee type
    // - Hourly: baseSalary * hoursWorked
    // - Salaried: baseSalary / 12
    // - Commission: baseSalary + (sales * commissionRate)
    public abstract BigDecimal calculateMonthlyCompensation();
    
    // ABSTRACT: Benefits eligibility varies by type
    public abstract boolean isEligibleForBonus();
    
    // ABSTRACT: Performance evaluation process differs
    public abstract PerformanceReview conductReview();
    
    protected void logTransfer(Department dept) { /* ... */ }
}
 
// Each employee type provides specific implementations
public class CommissionEmployee extends Employee {
    private BigDecimal commissionRate;
    private BigDecimal monthlySales;
    
    @Override
    public BigDecimal calculateMonthlyCompensation() {
        // Commission-specific calculation
        return baseSalary.add(monthlySales.multiply(commissionRate));
    }
    
    @Override
    public boolean isEligibleForBonus() {
        // Commission employees get bonus if sales exceed target
        return monthlySales.compareTo(SALES_TARGET) > 0;
    }
    
    @Override
    public PerformanceReview conductReview() {
        // Sales-focused evaluation
        return new SalesPerformanceReview(this);
    }
}

Scenario 3: Algorithm Variations (Template Method)

•You have an algorithm with a fixed structure
•Certain steps vary by situation
•You want to prevent skipping or reordering steps
•Examples: Data import pipelines, report generators, test frameworks, build systems

Scenario 4: Protected State with Controlled Access

•Subclasses need access to shared internal state
•This state should be hidden from external code
•State management logic is shared
•Examples: Connection pools, caching layers, resource managers with internal buffers

When NOT to Use Abstract Classes

Knowing when to avoid abstract classes is equally important. Here are scenarios where other mechanisms are preferable:

Scenarios Favoring Alternatives
Scenario	Why Abstract Class Fails	Better Alternative
No IS-A relationship	Inheritance implies type substitution; forced hierarchies are brittle	Composition + Interfaces
Multiple contracts needed	Single inheritance limits flexibility	Multiple interfaces
No shared implementation	Abstract class adds complexity without benefit	Pure interfaces
Behavior varies at runtime	Inheritance is compile-time fixed	Strategy pattern / Composition
Cross-cutting concerns	Would require diamond inheritance	Mixins, Traits, or Composition
Shallow, stable hierarchy	Over-engineering for simple cases	Concrete base class or none

A Detailed Anti-Example:

Consider a logging system where you might be tempted to create:

AntiExample
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
// ❌ BAD: Abstract class for logging
// Why is this wrong?
 
abstract class AbstractLogger {
    protected String prefix;
    
    public AbstractLogger(String prefix) {
        this.prefix = prefix;
    }
    
    // Trivial shared code - not worth abstract class
    protected String formatMessage(String message) {
        return "[" + prefix + "] " + message;
    }
    
    public abstract void log(String message);
}
 
class FileLogger extends AbstractLogger {
    public FileLogger() { super("FILE"); }
    
    @Override
    public void log(String message) {
        writeToFile(formatMessage(message));
    }
}
 
class ConsoleLogger extends AbstractLogger {
    public ConsoleLogger() { super("CONSOLE"); }
    
    @Override
    public void log(String message) {
        System.out.println(formatMessage(message));
    }
}
 
// PROBLEM: What if we need BOTH file AND console logging?
// Cannot extend two abstract classes!
// What if we need a logger that's also a MetricCollector?
// Single inheritance blocks this.
 
 
// ✅ GOOD: Interface + Composition
interface Logger {
    void log(String message);
}
 
interface MetricCollector {
    void recordMetric(String name, double value);
}
 
// Can implement multiple interfaces
class MonitoredFileLogger implements Logger, MetricCollector {
    private String prefix = "FILE";
    
    @Override
    public void log(String message) {
        writeToFile(formatMessage(message));
    }
    
    @Override
    public void recordMetric(String name, double value) {
        // ... metric recording
    }
    
    private String formatMessage(String msg) {
        return "[" + prefix + "] " + msg;  // Duplicated but simple
    }
}
 
// Composition for shared behavior
class CompositeLogger implements Logger {
    private final List<Logger> loggers;
    
    public CompositeLogger(Logger... loggers) {
        this.loggers = Arrays.asList(loggers);
    }
    
    @Override
    public void log(String message) {
        loggers.forEach(l -> l.log(message));  // Logs to ALL
    }
}

The Flexibility Principle

If you can foresee needing to combine behaviors from multiple sources, prefer interfaces. Abstract classes lock you into a single inheritance path. Interfaces allow unlimited composition.

Decision Tree for Abstraction Mechanism

Use this decision tree to select the right abstraction mechanism:

Question 1: Is there a genuine IS-A relationship?

No → Use composition with interfaces
Yes → Continue to Question 2

Question 2: Do you need to enforce specific method implementations?

No (defaults are fine) → Use concrete base class
Yes → Continue to Question 3

Question 3: Is there significant shared implementation to inherit?

No (only method signatures) → Use interface
Yes → Continue to Question 4

Question 4: Might implementations need multiple type identities?

Yes (implement multiple contracts) → Use interface + default methods or abstract class + interfaces
No (single hierarchy is sufficient) → Abstract class is appropriate

Question 5: Does the abstraction need to hold state?

Yes → Abstract class (interfaces can't have instance state)
No → Consider interface for maximum flexibility

DecisionExamples
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// EXAMPLE 1: Authentication strategies
// - IS-A? No, "EmailAuth IS-A AuthStrategy" sounds wrong
// - Shared state? No
// - Multiple implementations at runtime? Yes (strategy pattern)
// DECISION: Interface
 
interface AuthStrategy {
    boolean authenticate(Credentials credentials);
    String getProviderName();
}
 
// ---------------------------------------------------------
 
// EXAMPLE 2: Shape hierarchy
// - IS-A? Yes, "Circle IS-A Shape" is semantically correct
// - Shared implementation? Yes (color, position logic)
// - Enforced implementation? Yes (area, perimeter calculations)
// - Single hierarchy sufficient? Yes
// DECISION: Abstract Class
 
abstract class Shape {
    protected Color color;
    protected Point position;
    
    public void moveTo(Point newPosition) { /* shared */ }
    public Color getColor() { return color; }
    
    public abstract double getArea();
    public abstract double getPerimeter();
}
 
// ---------------------------------------------------------
 
// EXAMPLE 3: Plugin system
// - IS-A? Debatable ("MyPlugin IS-A Plugin" is okay)
// - Shared implementation? Minimal
// - Need to implement other contracts? Yes (Configurable, Startable)
// DECISION: Interfaces (multiple)
 
interface Plugin {
    String getName();
    void execute(PluginContext context);
}
 
interface Configurable {
    void configure(Configuration config);
}
 
interface Startable {
    void start();
    void stop();
}
 
// Plugin can implement all three
class MyPlugin implements Plugin, Configurable, Startable {
    // Maximum flexibility
}

Combining Abstract Classes with Interfaces

A powerful pattern combines abstract classes (for shared implementation) with interfaces (for type contracts). This provides the benefits of both:

Interface defines the contract — What operations must be supported
Abstract class provides partial implementation — How common cases work
Concrete classes complete the implementation — Specific behavior

CombiningPattern
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
// INTERFACE: Defines the contract (what)
public interface Collection<E> {
    int size();
    boolean isEmpty();
    boolean contains(Object o);
    boolean add(E element);
    boolean remove(Object o);
    Iterator<E> iterator();
    void clear();
}
 
// ABSTRACT CLASS: Provides skeletal implementation (how, partially)
public abstract class AbstractCollection<E> implements Collection<E> {
    
    // Implemented in terms of abstract methods
    public boolean isEmpty() {
        return size() == 0;  // Uses abstract size()
    }
    
    // Implemented in terms of iterator
    public boolean contains(Object o) {
        for (E element : this) {
            if (Objects.equals(element, o)) {
                return true;
            }
        }
        return false;
    }
    
    // Implemented in terms of iterator
    public void clear() {
        Iterator<E> it = iterator();
        while (it.hasNext()) {
            it.next();
            it.remove();
        }
    }
    
    // Useful toString implementation
    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder("[");
        // ... format elements
        return sb.toString();
    }
    
    // STILL ABSTRACT: Subclasses must provide these
    public abstract int size();
    public abstract Iterator<E> iterator();
    public abstract boolean add(E element);  // Often unsupported
}
 
// CONCRETE CLASS: Completes the implementation
public class ArrayList<E> extends AbstractCollection<E> implements List<E> {
    private Object[] elements;
    private int size;
    
    @Override
    public int size() {
        return size;  // Simple - just return field
    }
    
    @Override
    public Iterator<E> iterator() {
        return new ArrayListIterator();  // Specific implementation
    }
    
    @Override
    public boolean add(E element) {
        ensureCapacity();
        elements[size++] = element;
        return true;
    }
    
    // Inherits: isEmpty(), contains(), clear(), toString()
    // No code duplication!
}
 
// Another concrete class with different storage
public class LinkedList<E> extends AbstractCollection<E> implements List<E> {
    private Node<E> head;
    private int size;
    
    @Override
    public int size() {
        return size;
    }
    
    @Override
    public Iterator<E> iterator() {
        return new LinkedListIterator();  // Different iteration logic
    }
    
    @Override
    public boolean add(E element) {
        // Linked list add logic
        return true;
    }
    
    // ALSO inherits: isEmpty(), contains(), clear(), toString()
    // Correctly uses its own iterator!
}

Why This Pattern Is Powerful:

Flexible Typing — Code can depend on the interface (Collection), enabling any implementation
Reduced Boilerplate — Common implementations in AbstractCollection don't need to be rewritten
Direct Interface Implementation — If someone doesn't want the abstract class, they can implement the interface directly
Layered Abstractions — Java's Collections Framework uses this: Collection → Set → AbstractSet → HashSet

The "Skeletal Implementation" Pattern

This pattern is sometimes called "skeletal implementation" or "abstract interface implementation." It's used extensively in Java's Collections Framework (AbstractList, AbstractSet, AbstractMap) and is a best practice for library design.

Common Mistakes to Avoid

Even experienced developers make these mistakes when using abstract classes:

Abstract Class Anti-Patterns

•Using Abstract Class When Interface Suffices — If there's no shared implementation, an interface is simpler and more flexible. Don't use abstract classes just because "it feels more complete."
•Deep Inheritance Hierarchies — More than 2-3 levels of abstract classes becomes hard to understand. Prefer composition for additional functionality.
•Exposing Too Much Protected State — Protected fields are accessible to all subclasses, across all packages. This breaks encapsulation over time.
•Abstract Classes for Code Reuse Only — If there's no IS-A relationship, don't use inheritance. A User shouldn't extend JsonSerializable just to get serialization methods—use composition or mixins.
•Changing Abstract Methods After Release — Adding abstract methods breaks all existing subclasses. Use hook methods (concrete with default no-op) for optional extension points.
•God Abstract Classes — Abstract classes with dozens of methods are impossible to implement correctly. Keep them focused.

FixingMistakes
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// ❌ MISTAKE: Too much exposed state
abstract class BadBaseClass {
    protected List<String> items;      // Any subclass can corrupt this
    protected Map<String, Object> cache;  // Same problem
    protected boolean initialized;
    
    // Subclasses directly manipulate state, leading to bugs
}
 
// ✅ FIXED: Controlled access via methods
abstract class GoodBaseClass {
    private List<String> items = new ArrayList<>();  // Private
    private Map<String, Object> cache = new HashMap<>();
    private boolean initialized;
    
    // Protected METHODS provide controlled access
    protected void addItem(String item) {
        if (!initialized) throw new IllegalStateException();
        items.add(item);
    }
    
    protected List<String> getItemsCopy() {
        return new ArrayList<>(items);  // Defensive copy
    }
    
    protected void cacheValue(String key, Object value) {
        cache.put(key, value);
    }
    
    protected Optional<Object> getCached(String key) {
        return Optional.ofNullable(cache.get(key));
    }
}
 
// ❌ MISTAKE: Breaking existing subclasses by adding abstract method
abstract class Version1 {
    public abstract void process();
}
 
// Later, adding this breaks all existing implementations:
// public abstract void validate();  // Compile error for existing subclasses!
 
// ✅ FIXED: Use hook method for new optional behavior
abstract class Version2 {
    public abstract void process();
    
    // New in v2, but has default - doesn't break existing code
    protected void validate() {
        // Default: no-op, subclasses can override
    }
    
    // Template method uses both
    public final void processWithValidation() {
        validate();  // Optional hook
        process();   // Required abstract
    }
}

Summary and Next Steps

You now have a complete framework for deciding when abstract classes are the right design choice.

Key Takeaways

•Abstract classes require IS-A + shared code + enforced customization — All three conditions should be met for abstract classes to be the optimal choice.
•Single inheritance is a constraint — Abstract classes consume the one inheritance slot. Weigh this cost against the benefits.
•Ideal scenarios include frameworks, domain hierarchies, and algorithm templates — These naturally have shared behavior with required customization.
•Avoid abstract classes when flexibility is paramount — Multiple contracts, runtime behavior changes, or cross-cutting concerns favor interfaces and composition.
•Combine abstract classes with interfaces for maximum power — Define contracts via interfaces, provide skeletal implementations via abstract classes.
•Watch for anti-patterns — Deep hierarchies, exposed state, code-reuse-only inheritance, and breaking changes are common pitfalls.

What's Next:

The final page of this module compares abstract classes and interfaces directly. While we've touched on the differences, a systematic comparison will solidify your ability to choose correctly in any situation.

Page Complete

You now have a rigorous decision framework for when to use abstract classes. This knowledge prevents both overuse (unnecessary complexity) and underuse (missing out on code reuse and enforcement benefits).