Traditional Inheritance and Interfaces

Prior to the advent of sealed classes, developers primarily depended on a mix of inheritance and interfaces to gain a semblance of control over the inheritance structure. The conventional methods available—such as marking classes as final or using package-private visibility—proved to be somewhat effective but fell short in precision and flexibility, particularly for more intricate designs.

For instance, imagine you are developing an e-commerce application that accommodates various payment options, such as credit cards, PayPal, and Bitcoin.

public interface PaymentMethod {

void processPayment(double amount);

}

public class CreditCardPayment implements PaymentMethod {

public void processPayment(double amount) {

// Credit card payment logic

}

}

public class PayPalPayment implements PaymentMethod {

public void processPayment(double amount) {

// PayPal payment logic

}

}

public class BitcoinPayment implements PaymentMethod {

public void processPayment(double amount) {

// Bitcoin payment logic

}

}

While this method functions adequately, it lacks the ability to limit which classes can inherit from PaymentMethod, potentially leading to a cluttered class hierarchy.

Utilizing Sealed Classes

With the introduction of sealed classes, developers can now define a closed group of allowed subclasses, ensuring a well-defined and maintainable inheritance hierarchy.

public sealed interface PaymentMethod permits CreditCardPayment, PayPalPayment, BitcoinPayment {

void processPayment(double amount);

}

public final class CreditCardPayment implements PaymentMethod {

public void processPayment(double amount) {

// Credit card payment logic

}

}

public final class PayPalPayment implements PaymentMethod {

public void processPayment(double amount) {

// PayPal payment logic

}

}

public final class BitcoinPayment implements PaymentMethod {

public void processPayment(double amount) {

// Bitcoin payment logic

}

}

In this scenario, the PaymentMethod interface is declared as sealed, with the permits clause designating the classes that are allowed to implement it: CreditCardPayment, PayPalPayment, and BitcoinPayment. These classes are also marked as final, ensuring that they cannot be extended further.

Benefits of Sealed Classes

1. Enhanced Maintainability: By limiting the set of permissible subclasses, sealed classes contribute to a more maintainable codebase, allowing developers to easily understand possible implementations and their behaviors.
2. Increased Type Safety: Defining a closed set of permissible subclasses minimizes the risk of unforeseen extensions or implementations, thereby decreasing bugs and bolstering the overall type safety of the application.
3. Improved Exhaustiveness Checking: When combined with pattern matching (introduced in Java 17), sealed classes enable the compiler to perform exhaustiveness checks, ensuring that all scenarios are covered in a switch statement or other control flow constructs.

public void processPayment(PaymentMethod paymentMethod, double amount) {

switch (paymentMethod) {

case CreditCardPayment creditCard -> creditCard.processPayment(amount);

case PayPalPayment payPal -> payPal.processPayment(amount);

case BitcoinPayment bitcoin -> bitcoin.processPayment(amount);

}

}

Limitations of Sealed Classes

1. Compile-time Constraints: Sealed classes necessitate that all allowed subclasses be defined at compile-time, which can pose limitations in situations where subclasses may need to be added dynamically.
2. Cross-module Restrictions: When utilizing sealed classes across different modules, additional constraints come into play, including the requirement that permitted subclasses be located in the same module as the sealed class (or within the same package if in the unnamed module).
3. Design Commitment: Choosing to implement sealed classes requires developers to have a solid understanding of their class hierarchy from the outset. This demands a certain commitment to class design early in the development cycle, which may not always be practical, especially for projects with evolving requirements.
4. Extension Limitations: By strictly regulating which classes can extend a sealed class, developers may find themselves hindered, particularly when attempting to enhance functionality in libraries or frameworks that were not designed for certain extensions.