Abstract Classes vs Interfaces - Learning Module

Loading content...

0/246

Abstract Class — Partial Implementation

The Template Paradox

In software design, we frequently encounter a compelling dilemma: How do we provide a reusable template that enforces structure while allowing customization?

Consider building a payment processing system. Every payment—whether credit card, PayPal, or cryptocurrency—shares common validation logic, logging mechanisms, and error handling patterns. Yet each payment type requires fundamentally different processing implementations. You want to enforce that every payment processor includes validation. You want to provide shared logging infrastructure. But you cannot provide a universal processing algorithm—that must be customized.

This is the domain of abstract classes: constructs that live between fully concrete classes (which provide complete implementations) and pure interfaces (which provide no implementation at all). Abstract classes offer partial implementation—a powerful middle ground that enables sophisticated code reuse while maintaining extensibility.

What You Will Learn

By the end of this page, you will deeply understand abstract classes as partial implementation mechanisms. You'll grasp why they exist, how they function at both conceptual and mechanical levels, and when they provide irreplaceable value in software design.

What Is an Abstract Class?

An abstract class is a class that cannot be instantiated directly and may contain both abstract methods (without implementation) and concrete methods (with implementation). It serves as a blueprint—a partially completed template—that subclasses must complete.

The Defining Characteristics:

Cannot be instantiated directly: You cannot create objects of an abstract class. It exists solely to be extended.
May contain abstract methods: These are method signatures without bodies. Subclasses must provide implementations.
May contain concrete methods: These are fully implemented methods that subclasses inherit directly or can override.
May contain state (fields): Unlike interfaces in most languages, abstract classes can maintain instance variables with any visibility.
Supports constructors: Abstract classes can have constructors, invoked when subclasses are instantiated.

This combination—abstract methods that require implementation plus concrete methods that provide implementation—is what makes abstract classes uniquely powerful.

AbstractClass.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
// Abstract class definition
public abstract class Document {
    
    // Instance field - abstract classes can have state
    protected String title;
    protected Date createdAt;
    
    // Constructor - invoked by subclass constructors
    public Document(String title) {
        this.title = title;
        this.createdAt = new Date();
    }
    
    // Abstract method - NO implementation
    // Subclasses MUST provide their own implementation
    public abstract void render();
    
    // Abstract method - forces subclasses to define format
    public abstract String getFileExtension();
    
    // Concrete method - fully implemented
    // Subclasses inherit this behavior automatically
    public String getTitle() {
        return this.title;
    }
    
    // Concrete method with complex logic
    // Provides shared functionality to all subclasses
    public void logAccess(String userId) {
        System.out.println(
            String.format("[%s] User %s accessed document: %s",
                new Date(), userId, this.title)
        );
        // Additional logging, metrics, audit trail...
    }
    
    // Concrete method that calls abstract method
    // Template Method pattern in action
    public void saveToFile(String directory) {
        String filename = this.title + "." + getFileExtension();
        String path = directory + "/" + filename;
        render(); // Abstract - subclass determines how
        System.out.println("Saved to: " + path);
    }
}

Language Variations

Most object-oriented languages support abstract classes (Java, C#, C++, TypeScript, Python via ABC). The syntax varies, but the concept remains consistent: a class that provides partial implementation and cannot be instantiated directly.

The Mechanics of Partial Implementation

Understanding how abstract classes achieve partial implementation requires examining their dual nature: they are simultaneously templates (defining what must exist) and libraries (providing what already exists).

The Template Aspect: Abstract Methods

Abstract methods define slots that subclasses must fill. They declare:

Method signature (name, parameters, return type)
The promise that this behavior will exist
Nothing about how the behavior works

This creates a contract between the abstract class and its subclasses: "I will provide you with shared infrastructure, but you must implement these specific behaviors."

The Library Aspect: Concrete Methods

Concrete methods provide ready-to-use functionality. They offer:

Fully implemented behavior
Code reuse across all subclasses
A consistent baseline that specializations build upon

Subclasses receive these methods "for free"—no reimplementation required. They can override if needed, but the default works immediately.

PartialImplementation.java
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
// The abstract class provides PARTIAL implementation
public abstract class NotificationSender {
    
    // Shared state across all notification types
    protected final Logger logger;
    protected final MetricsClient metrics;
    protected final RateLimiter rateLimiter;
    
    // Constructor initializes shared infrastructure
    public NotificationSender(Logger logger, MetricsClient metrics) {
        this.logger = logger;
        this.metrics = metrics;
        this.rateLimiter = new RateLimiter(100); // 100 per minute
    }
    
    // ═══════════════════════════════════════════════════
    // ABSTRACT METHODS: Template slots subclasses fill
    // ═══════════════════════════════════════════════════
    
    // Each notification type knows its own delivery mechanism
    protected abstract void deliverNotification(
        String recipient, 
        String message
    ) throws DeliveryException;
    
    // Each type validates recipients differently
    protected abstract boolean isValidRecipient(String recipient);
    
    // Each type has its own retry strategy
    protected abstract int getMaxRetries();
    
    // ═══════════════════════════════════════════════════
    // CONCRETE METHODS: Shared functionality provided
    // ═══════════════════════════════════════════════════
    
    // Main send method - orchestrates the process
    // Uses abstract methods, wraps with shared logic
    public final boolean send(String recipient, String message) {
        // Shared validation
        if (!isValidRecipient(recipient)) {
            logger.warn("Invalid recipient: {}", recipient);
            metrics.increment("notification.invalid_recipient");
            return false;
        }
        
        // Shared rate limiting
        if (!rateLimiter.tryAcquire()) {
            logger.warn("Rate limit exceeded for notifications");
            metrics.increment("notification.rate_limited");
            return false;
        }
        
        // Shared retry logic using abstract method for specifics
        int attempts = 0;
        int maxRetries = getMaxRetries(); // Abstract
        
        while (attempts < maxRetries) {
            try {
                long start = System.currentTimeMillis();
                
                deliverNotification(recipient, message); // Abstract
                
                long duration = System.currentTimeMillis() - start;
                metrics.recordLatency("notification.delivery", duration);
                metrics.increment("notification.success");
                logger.info("Notification sent to {} in {}ms", recipient, duration);
                return true;
                
            } catch (DeliveryException e) {
                attempts++;
                logger.warn("Delivery attempt {} failed: {}", attempts, e.getMessage());
                metrics.increment("notification.retry");
                
                if (attempts < maxRetries) {
                    sleepWithExponentialBackoff(attempts);
                }
            }
        }
        
        metrics.increment("notification.failed");
        logger.error("All {} delivery attempts failed for {}", maxRetries, recipient);
        return false;
    }
    
    // Shared utility method
    private void sleepWithExponentialBackoff(int attempt) {
        try {
            Thread.sleep((long) Math.pow(2, attempt) * 100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

The Power of This Design:

Notice how the abstract class provides substantial value:

Shared infrastructure: Logger, metrics, and rate limiter are configured once
Consistent orchestration: The send() method ensures every notification follows the same validation → rate-limit → retry flow
Customization points: Subclasses only implement what's unique to them
DRY principle: No duplication of logging, metrics, or retry logic across notification types

When we create concrete implementations, we inherit all this machinery:

ConcreteImplementations.java
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
103
104
105
106
107
108
109
110
111
112
// Concrete implementation for email notifications
public class EmailNotificationSender extends NotificationSender {
    
    private final SmtpClient smtpClient;
    
    public EmailNotificationSender(
        Logger logger, 
        MetricsClient metrics, 
        SmtpClient smtpClient
    ) {
        super(logger, metrics); // Initialize shared infrastructure
        this.smtpClient = smtpClient;
    }
    
    @Override
    protected void deliverNotification(String recipient, String message) 
        throws DeliveryException {
        // Email-specific delivery logic
        EmailMessage email = EmailMessage.builder()
            .to(recipient)
            .subject("Notification")
            .body(message)
            .build();
        smtpClient.send(email);
    }
    
    @Override
    protected boolean isValidRecipient(String recipient) {
        // Email-specific validation
        return recipient != null 
            && recipient.contains("@") 
            && recipient.contains(".");
    }
    
    @Override
    protected int getMaxRetries() {
        return 3; // Email can retry more - async by nature
    }
}
 
 
// Concrete implementation for SMS notifications
public class SmsNotificationSender extends NotificationSender {
    
    private final TwilioClient twilioClient;
    
    public SmsNotificationSender(
        Logger logger, 
        MetricsClient metrics, 
        TwilioClient twilioClient
    ) {
        super(logger, metrics);
        this.twilioClient = twilioClient;
    }
    
    @Override
    protected void deliverNotification(String recipient, String message) 
        throws DeliveryException {
        // SMS-specific delivery logic
        if (message.length() > 160) {
            message = message.substring(0, 157) + "...";
        }
        twilioClient.sendSms(recipient, message);
    }
    
    @Override
    protected boolean isValidRecipient(String recipient) {
        // Phone number validation
        return recipient != null 
            && recipient.matches("^\+?[1-9]\d{9,14}$");
    }
    
    @Override
    protected int getMaxRetries() {
        return 2; // SMS is expensive - fewer retries
    }
}
 
 
// Concrete implementation for push notifications
public class PushNotificationSender extends NotificationSender {
    
    private final FirebaseClient firebaseClient;
    
    public PushNotificationSender(
        Logger logger, 
        MetricsClient metrics, 
        FirebaseClient firebaseClient
    ) {
        super(logger, metrics);
        this.firebaseClient = firebaseClient;
    }
    
    @Override
    protected void deliverNotification(String recipient, String message) 
        throws DeliveryException {
        // Push-specific delivery
        PushPayload payload = new PushPayload(message);
        firebaseClient.sendToDevice(recipient, payload);
    }
    
    @Override
    protected boolean isValidRecipient(String recipient) {
        // Device token validation
        return recipient != null && recipient.length() == 152;
    }
    
    @Override
    protected int getMaxRetries() {
        return 5; // Push is cheap - retry aggressively
    }
}

The 80/20 Rule of Abstract Classes

Well-designed abstract classes often provide 80% of the functionality, requiring subclasses to implement only the 20% that's truly unique. If your abstract class provides very little—or requires subclasses to implement most methods—you might want an interface instead.

Abstract Classes as Templates — The Template Method Pattern

One of the most powerful applications of abstract classes is the Template Method Pattern—a behavioral design pattern where an abstract class defines the skeleton of an algorithm, deferring specific steps to subclasses.

This pattern leverages partial implementation perfectly:

The template method (concrete) defines the algorithm structure
Hook methods (abstract or default) allow subclasses to customize steps
The overall flow is invariant—subclasses cannot change the algorithm's shape

Consider a data processing pipeline:

TemplateMethod.java
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
// Template Method Pattern in action
public abstract class DataProcessor<T, R> {
    
    // ═══════════════════════════════════════════════════
    // TEMPLATE METHOD: Defines the invariant algorithm
    // This method is 'final' - subclasses cannot override
    // ═══════════════════════════════════════════════════
    public final ProcessingResult<R> process(DataSource<T> source) {
        
        // Step 1: Validate input (concrete - shared logic)
        if (!validateSource(source)) {
            return ProcessingResult.failure("Invalid data source");
        }
        
        // Step 2: Pre-processing hook (subclass can customize)
        preProcess(source);
        
        // Step 3: Extract data (abstract - must implement)
        List<T> rawData = extractData(source);
        
        // Step 4: Transform data (abstract - must implement)
        List<R> transformedData = new ArrayList<>();
        for (T item : rawData) {
            R transformed = transform(item);
            if (filter(transformed)) { // Abstract filter
                transformedData.add(transformed);
            }
        }
        
        // Step 5: Post-processing hook (subclass can customize)
        postProcess(transformedData);
        
        // Step 6: Build result (concrete - shared logic)
        return buildResult(transformedData);
    }
    
    // ═══════════════════════════════════════════════════
    // CONCRETE METHODS: Shared implementation
    // ═══════════════════════════════════════════════════
    
    // Validation logic shared by all processors
    private boolean validateSource(DataSource<T> source) {
        return source != null 
            && source.isConnected() 
            && source.hasData();
    }
    
    // Result building shared by all processors
    private ProcessingResult<R> buildResult(List<R> data) {
        return ProcessingResult.success(data, data.size());
    }
    
    // ═══════════════════════════════════════════════════
    // HOOK METHODS: Optional customization points
    // Default implementation does nothing
    // ═══════════════════════════════════════════════════
    
    protected void preProcess(DataSource<T> source) {
        // Default: no pre-processing
        // Subclasses can override to add setup logic
    }
    
    protected void postProcess(List<R> data) {
        // Default: no post-processing
        // Subclasses can override to add cleanup logic
    }
    
    // ═══════════════════════════════════════════════════
    // ABSTRACT METHODS: Subclasses MUST implement
    // ═══════════════════════════════════════════════════
    
    // How to extract raw data from the source
    protected abstract List<T> extractData(DataSource<T> source);
    
    // How to transform each item
    protected abstract R transform(T item);
    
    // Which items to keep after transformation
    protected abstract boolean filter(R item);
}

Why This Design Is Powerful:

Invariant structure: The process() method is final—no subclass can break the validate → extract → transform → filter flow
Guaranteed extensibility: Subclasses must provide the core operations, ensuring complete implementations
Optional hooks: preProcess() and postProcess() have default (empty) implementations—subclasses override only if needed
DRY principle: Validation and result-building are implemented once, used everywhere
Type safety: Generics ensure type consistency through the pipeline

ConcreteProcessors.java
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
// CSV processor implementation
public class CsvToJsonProcessor 
    extends DataProcessor<String[], JsonObject> {
    
    private final String[] headers;
    
    public CsvToJsonProcessor(String[] headers) {
        this.headers = headers;
    }
    
    @Override
    protected void preProcess(DataSource<String[]> source) {
        // Skip header row
        source.skipFirst();
    }
    
    @Override
    protected List<String[]> extractData(DataSource<String[]> source) {
        // CSV-specific extraction
        return source.readAllRows();
    }
    
    @Override
    protected JsonObject transform(String[] csvRow) {
        JsonObject json = new JsonObject();
        for (int i = 0; i < headers.length && i < csvRow.length; i++) {
            json.addProperty(headers[i], csvRow[i]);
        }
        return json;
    }
    
    @Override
    protected boolean filter(JsonObject item) {
        // Keep only records with non-empty required fields
        return item.has("id") && !item.get("id").isJsonNull();
    }
}
 
 
// Database processor implementation
public class DatabaseToReportProcessor 
    extends DataProcessor<ResultRow, ReportEntry> {
    
    private final ReportFormatter formatter;
    
    public DatabaseToReportProcessor(ReportFormatter formatter) {
        this.formatter = formatter;
    }
    
    @Override
    protected List<ResultRow> extractData(DataSource<ResultRow> source) {
        // Execute query and fetch results
        return source.executeQuery("SELECT * FROM transactions");
    }
    
    @Override
    protected ReportEntry transform(ResultRow row) {
        return ReportEntry.builder()
            .id(row.getLong("id"))
            .amount(row.getBigDecimal("amount"))
            .date(row.getDate("created_at"))
            .formatted(formatter.format(row))
            .build();
    }
    
    @Override
    protected boolean filter(ReportEntry entry) {
        // Only include entries from last 30 days
        return entry.getDate().isAfter(
            LocalDate.now().minusDays(30)
        );
    }
    
    @Override
    protected void postProcess(List<ReportEntry> data) {
        // Sort by date descending
        data.sort(Comparator.comparing(ReportEntry::getDate).reversed());
    }
}

The Hollywood Principle

The Template Method Pattern exemplifies the Hollywood Principle: "Don't call us, we'll call you." The abstract class controls the flow and calls subclass methods at appropriate times—subclasses don't drive the process, they merely implement the customizable parts.

State and Construction in Abstract Classes

A critical differentiator of abstract classes is their ability to maintain state and define constructors. This capability enables sophisticated infrastructure sharing that interfaces cannot match.

Instance Fields in Abstract Classes:

Abstract classes can declare instance variables with any visibility:

private fields accessible only within the abstract class
protected fields accessible to subclasses
Public fields (rarely appropriate in good design)

This state is shared across all concrete methods and inherited by subclasses, enabling patterns where the abstract class manages infrastructure while subclasses focus on business logic.

AbstractClassState.java
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
103
104
105
106
// Abstract class with rich state management
public abstract class CacheableRepository<T, ID> {
    
    // ═══════════════════════════════════════════════════
    // INSTANCE STATE: Shared infrastructure
    // ═══════════════════════════════════════════════════
    
    // Private - managed entirely by abstract class
    private final Cache<ID, T> cache;
    private final AtomicLong cacheHits;
    private final AtomicLong cacheMisses;
    
    // Protected - accessible to subclasses
    protected final Logger logger;
    protected final DataSource dataSource;
    
    // ═══════════════════════════════════════════════════
    // CONSTRUCTOR: Establishes shared infrastructure
    // ═══════════════════════════════════════════════════
    
    protected CacheableRepository(
        DataSource dataSource,
        CacheConfig cacheConfig,
        Logger logger
    ) {
        this.dataSource = dataSource;
        this.logger = logger;
        
        // Initialize private cache infrastructure
        this.cache = CacheBuilder.newBuilder()
            .maximumSize(cacheConfig.getMaxSize())
            .expireAfterWrite(cacheConfig.getTtl())
            .recordStats()
            .build();
        
        this.cacheHits = new AtomicLong(0);
        this.cacheMisses = new AtomicLong(0);
        
        logger.info(
            "Initialized {} with cache size {} and TTL {}",
            getClass().getSimpleName(),
            cacheConfig.getMaxSize(),
            cacheConfig.getTtl()
        );
    }
    
    // ═══════════════════════════════════════════════════
    // CONCRETE METHODS: Use private state for caching
    // ═══════════════════════════════════════════════════
    
    public Optional<T> findById(ID id) {
        // Check cache first
        T cached = cache.getIfPresent(id);
        if (cached != null) {
            cacheHits.incrementAndGet();
            logger.debug("Cache hit for id: {}", id);
            return Optional.of(cached);
        }
        
        cacheMisses.incrementAndGet();
        logger.debug("Cache miss for id: {}", id);
        
        // Delegate to subclass for actual fetch
        Optional<T> result = fetchFromDatabase(id);
        
        // Populate cache
        result.ifPresent(entity -> cache.put(id, entity));
        
        return result;
    }
    
    public T save(T entity) {
        ID id = extractId(entity); // Abstract method
        
        // Delegate to subclass for persistence
        T saved = persistToDatabase(entity);
        
        // Update cache
        cache.put(id, saved);
        logger.debug("Saved and cached entity with id: {}", id);
        
        return saved;
    }
    
    public void evictFromCache(ID id) {
        cache.invalidate(id);
        logger.debug("Evicted from cache: {}", id);
    }
    
    public CacheStatistics getCacheStatistics() {
        return new CacheStatistics(
            cacheHits.get(),
            cacheMisses.get(),
            cache.size(),
            cache.stats()
        );
    }
    
    // ═══════════════════════════════════════════════════
    // ABSTRACT METHODS: Subclasses implement data access
    // ═══════════════════════════════════════════════════
    
    protected abstract Optional<T> fetchFromDatabase(ID id);
    protected abstract T persistToDatabase(T entity);
    protected abstract ID extractId(T entity);
}

Constructor Chaining in Hierarchies:

Abstract class constructors enable proper initialization of shared state. When a subclass is instantiated:

The subclass constructor calls super(...) to invoke the abstract class constructor
The abstract class constructor initializes shared infrastructure
The subclass constructor completes subclass-specific initialization

This ensures that shared infrastructure is always properly configured before subclass logic runs.

ConstructorChaining.java
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
// Concrete repository extending the abstract class
public class UserRepository extends CacheableRepository<User, Long> {
    
    private final UserRowMapper rowMapper;
    private final PasswordEncoder passwordEncoder;
    
    // Constructor MUST call super() to initialize cache infrastructure
    public UserRepository(
        DataSource dataSource,
        CacheConfig cacheConfig,
        Logger logger,
        PasswordEncoder passwordEncoder
    ) {
        // Initialize shared caching infrastructure first
        super(dataSource, cacheConfig, logger);
        
        // Then initialize subclass-specific dependencies
        this.rowMapper = new UserRowMapper();
        this.passwordEncoder = passwordEncoder;
    }
    
    @Override
    protected Optional<User> fetchFromDatabase(Long id) {
        // Subclass-specific SQL logic
        // Uses inherited 'dataSource' and 'logger' from abstract class
        String sql = "SELECT * FROM users WHERE id = ?";
        
        try (Connection conn = dataSource.getConnection();
             PreparedStatement stmt = conn.prepareStatement(sql)) {
            
            stmt.setLong(1, id);
            ResultSet rs = stmt.executeQuery();
            
            if (rs.next()) {
                return Optional.of(rowMapper.map(rs));
            }
            return Optional.empty();
            
        } catch (SQLException e) {
            logger.error("Failed to fetch user {}: {}", id, e.getMessage());
            throw new RepositoryException("Database error", e);
        }
    }
    
    @Override
    protected User persistToDatabase(User user) {
        // Hash password before persisting
        if (user.getPassword() != null && !user.isPasswordHashed()) {
            user.setPassword(passwordEncoder.encode(user.getPassword()));
            user.setPasswordHashed(true);
        }
        
        // Implementation for INSERT/UPDATE...
        return user;
    }
    
    @Override
    protected Long extractId(User user) {
        return user.getId();
    }
}

Constructor Order Matters

Abstract class constructors run BEFORE subclass constructors complete. Never call abstract methods from an abstract class constructor—the subclass hasn't been fully initialized yet, leading to subtle bugs where overridden methods access uninitialized subclass fields.

Visibility and Access Control

Abstract classes provide fine-grained control over visibility—something interfaces cannot match. Understanding how to use access modifiers effectively is crucial for designing robust abstract class hierarchies.

Protected: The Sweet Spot

protected visibility is particularly powerful in abstract classes:

Abstract methods are often protected—meant for subclasses to implement but not for external callers
Fields that subclasses need access to should be protected, not public
Helper methods for subclass use should be protected

Private: Infrastructure Encapsulation

private members in abstract classes create implementation details that subclasses cannot see or modify:

Internal state management (caches, metrics, connection pools)
Helper methods that subclasses shouldn't override
Implementation decisions that might change without affecting subclasses

Access Modifier Usage in Abstract Classes
Modifier	Visible to Subclasses	Best Used For
`public`	Yes	API methods called by external code; the class's contract with the world
`protected`	Yes	Abstract methods; fields and helpers subclasses need; extension points
`private`	No	Internal infrastructure; implementation details; invariant protection
`package` (default)	Same package only	Internal coordination; rarely used in abstract class hierarchies

VisibilityDesign.java
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
public abstract class HttpClient {
    
    // ─────────────────────────────────────────────────────
    // PRIVATE: Internal infrastructure subclasses can't touch
    // ─────────────────────────────────────────────────────
    
    private final ConnectionPool connectionPool;
    private final CircuitBreaker circuitBreaker;
    private final AtomicInteger activeRequests;
    
    // ─────────────────────────────────────────────────────
    // PROTECTED: Subclasses can access but external code cannot
    // ─────────────────────────────────────────────────────
    
    protected final Logger logger;
    protected final HttpClientConfig config;
    
    // Protected constructor - subclasses call, external code cannot
    protected HttpClient(HttpClientConfig config) {
        this.config = config;
        this.logger = LoggerFactory.getLogger(getClass());
        
        // Private infrastructure initialized here
        this.connectionPool = new ConnectionPool(config.getPoolSize());
        this.circuitBreaker = new CircuitBreaker(config.getCircuitConfig());
        this.activeRequests = new AtomicInteger(0);
    }
    
    // ─────────────────────────────────────────────────────
    // PUBLIC: External API - what callers use
    // ─────────────────────────────────────────────────────
    
    public final HttpResponse execute(HttpRequest request) {
        // Check circuit breaker (private infrastructure)
        if (!circuitBreaker.allowRequest()) {
            return HttpResponse.serviceUnavailable();
        }
        
        activeRequests.incrementAndGet();
        try {
            // Get connection from pool (private infrastructure)
            Connection conn = connectionPool.acquire();
            try {
                return executeWithConnection(request, conn);
            } finally {
                connectionPool.release(conn);
            }
        } finally {
            activeRequests.decrementAndGet();
        }
    }
    
    // Public status method
    public ClientStatus getStatus() {
        return new ClientStatus(
            activeRequests.get(),
            connectionPool.getAvailableCount(),
            circuitBreaker.getState()
        );
    }
    
    // ─────────────────────────────────────────────────────
    // PROTECTED ABSTRACT: Subclasses implement, external cannot call
    // ─────────────────────────────────────────────────────
    
    protected abstract HttpResponse executeWithConnection(
        HttpRequest request, 
        Connection connection
    );
    
    // ─────────────────────────────────────────────────────
    // PROTECTED: Helper methods for subclasses
    // ─────────────────────────────────────────────────────
    
    protected void logRequestStart(HttpRequest request) {
        logger.debug("Starting {} {}", request.getMethod(), request.getUrl());
    }
    
    protected void logRequestComplete(HttpRequest request, long durationMs) {
        logger.debug(
            "Completed {} {} in {}ms", 
            request.getMethod(), 
            request.getUrl(), 
            durationMs
        );
    }
    
    // ─────────────────────────────────────────────────────
    // PRIVATE: Internal helpers subclasses shouldn't touch
    // ─────────────────────────────────────────────────────
    
    private void recordCircuitBreakerEvent(boolean success) {
        if (success) {
            circuitBreaker.recordSuccess();
        } else {
            circuitBreaker.recordFailure();
        }
    }
}

Design for Inheritance or Prohibit It

When designing abstract classes, be intentional about what subclasses can access. Document protected methods as extension points. Mark methods that must not be overridden as 'final'. Hide implementation details as private. This explicit design prevents subclasses from depending on internals you might need to change.

Summary: Abstract Classes as Partial Implementation

We've explored abstract classes in depth, understanding their role as partial implementation mechanisms in object-oriented design. Let's consolidate the key insights:

Key Takeaways

•Abstract classes combine abstract and concrete methods — They are templates that provide shared functionality while requiring subclasses to implement specific behaviors.
•They enable sophisticated code reuse — Unlike interfaces, abstract classes can provide substantial implementation that all subclasses inherit automatically.
•They can maintain state — Instance fields, constructors, and visibility modifiers allow abstract classes to manage shared infrastructure.
•Template Method Pattern is the canonical use case — Abstract classes excel when you want to define an algorithm's structure while allowing customization of specific steps.
•Visibility modifiers provide control — Protected and private members enable fine-grained access control that interfaces cannot match.
•Constructor chaining ensures proper initialization — Abstract class constructors guarantee shared infrastructure is ready before subclass logic runs.

What's Next:

With a solid understanding of abstract classes as partial implementation mechanisms, we're ready to explore their counterpart: interfaces as pure contracts. While abstract classes provide some implementation, interfaces traditionally provide none—defining only what must exist, never how. Understanding this distinction is crucial for choosing the right abstraction mechanism for each design situation.

Page Complete

You now understand abstract classes as partial implementation mechanisms—powerful constructs that combine template behavior with concrete functionality. Next, we'll contrast this with interfaces, which take the opposite approach: pure contracts with no implementation.