All 15 Design Patterns in Java questions
More in Design Patterns in Java
How would you implement the Composite pattern to treat individual objects and groups of objects uniformly, such as a file system with files and directories? How would you implement the Observer pattern in Java, and how does it compare to using the built-in PropertyChangeSupport or a reactive streams library? How would you implement the Decorator pattern in Java, and how does java.io's InputStream/OutputStream class hierarchy exemplify this pattern in the JDK itself? How would you implement the Dependency Injection pattern manually (without a framework like Spring) using constructor injection, and what testability benefits does this provide? How would you use the Chain of Responsibility pattern to implement a request-processing pipeline (such as middleware-style validation/authentication/logging), and how does this relate conceptually to servlet filters or web framework middleware? How would you implement the Proxy pattern to add lazy initialization to an expensive-to-create object, and how does this differ structurally from the Decorator pattern despite both wrapping an object behind a shared interface?
Advertisement
Back to results for “Design Patterns in Java”
Java › Design Patterns in Java

How would you implement the Visitor pattern in Java to add new operations to an existing class hierarchy without modifying those classes, and how do Java's sealed classes and pattern matching (switch expressions) provide a modern alternative?

Advanced

Answer

The classic Visitor pattern uses double-dispatch (each element class has an accept(Visitor) method calling back into a corresponding visit(ConcreteElement) method on the visitor) to let you add new operations over a fixed set of element types without modifying those types themselves, at the cost of considerable boilerplate and difficulty adding new element types later; Java's sealed classes (restricting which classes can implement/extend an interface) combined with exhaustive pattern-matching switch expressions (Java 17+/21+) provide a much more concise, compiler-checked alternative for exactly this "closed set of types, add new operations" scenario, since the compiler can verify at compile time that a switch expression handles every possible sealed subtype, without any of the classic Visitor pattern's boilerplate.
// Modern alternative using sealed interfaces and pattern matching (Java 21+)
sealed interface Shape permits Circle, Rectangle, Triangle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}
record Triangle(double base, double height) implements Shape {}

double area(Shape shape) {
    return switch (shape) {
        case Circle c -> Math.PI * c.radius() * c.radius();
        case Rectangle r -> r.width() * r.height();
        case Triangle t -> 0.5 * t.base() * t.height();
        // compiler ERRORS if a new Shape subtype is added and this switch isn't updated -- exhaustiveness checking
    };
}
Real-world example A geometry library modeling shapes as a sealed hierarchy uses exhaustive pattern-matching switch expressions to implement operations like area() and perimeter(), gaining the same 'add new operations easily' benefit the classic Visitor pattern provided, but with compiler-enforced exhaustiveness checking and dramatically less boilerplate than hand-writing accept()/visit() methods across every class.

Common follow-ups: What specific scenario still favors the classic double-dispatch Visitor pattern over sealed classes and pattern matching?;How does sealed class exhaustiveness checking actually work at compile time?

Records & Sealed Classes;Pattern Matching & Switch Expressions
All 15 Design Patterns in Java questions