Home » Java » Core Java » instanceof operator and Visitor pattern replacement in Java 8

About Tomasz Nurkiewicz

Java EE developer, Scala enthusiast. Enjoying data analysis and visualization. Strongly believes in the power of testing and automation.

instanceof operator and Visitor pattern replacement in Java 8

I had a dream where instanceof operator and downcasting were no longer needed but without clumsiness and verbosity of visitor pattern. So I came up with the following DSL syntax:
 
 
 
 
 
 
 
 

Object msg = //...
 
whenTypeOf(msg).
    is(Date.class).    then(date -> println(date.getTime())).
    is(String.class).  then(str -> println(str.length())).
    is(Number.class).  then(num -> println(num.intValue())).
                     orElse(obj -> println("Unknown " + obj));

No downcasting, clean syntax, strong-typed and… perfectly achievable in Java 8. Using lambdas and a little bit of generics I created a tiny library called typeof that is clean, easy to use and more robust than instanceof and Visitor pattern taken together. Advantages include:

  • no explicit downcasting
  • avoids instanceof
  • clean and easy to use
  • strongly typed
  • works with classes that we have no control over, including JDK

This small utility was developed with Akka and Java API in mind to limit the usage of instanceof operator, but it’s much more general. Similarly you can return something depending on the runtime type:

int result = whenTypeOf(obj).
    is(String.class).thenReturn(String::length).
    is(Date.class).thenReturn(d -> (int) d.getTime()).
    is(Number.class).thenReturn(Number::intValue).
    is(TimeZone.class).thenReturn(tz -> tz.getRawOffset() / 1000).
    is(MyType.class).thenReturn(7).
    get();

The library examines every is() clause from top to bottom and stops if it finds first matching class, including parent classes – so is(Number.class) will match both Integer and Float. If none of the conditions matched, calling get will fail with exception. You can override this behaviour using orElse() (easier to read than equivalent is(Object.class)):

int result = whenTypeOf(obj).
    is(String.class).thenReturn(String::length).
    //...
    orElse(42);

DSL takes advantage of static typing in Java, making it nearly impossible to use the library incorrectly – most mistakes are caught immediately during compilation. All code snippets below won’t even compile:

//ERROR - two subsequent is()
whenTypeOf(obj).
    is(Foo.class).is(Bar.class)
 
//ERROR - then() without prior is()
whenTypeOf(obj).
    then(x -> println(x))
 
//ERROR - mixing then() and thenReturn()
whenTypeOf(obj).
    is(Foo.class).then(foo -> println(foo)).
    is(Bar.class).thenReturn(bar -> bar.getB());

Basically you start by typing whenTypeOf() and Ctrl + space will tell you precisely what is allowed. The key to designing type-safe and robust DSLs in statically typed languages is to limit the API as much as possible so that invalid states and calls are avoided at compile time. You will end up with a proliferation of tiny classes, but that’s OK, your users won’t see this. For example check out FirstIs.java – an object returned after first is() invocation:

public class FirstIs<S, T> {
    final Then<S> parent;
    private final S object;
    private final Class<T> expectedType;
 
    public Then<S> then(Consumer<T> thenBlock) {
        if (matchingType()) {
            thenBlock.accept(castObject());
            return new TerminalThen<>();
        }
        return parent;
    }
 
    public <R> ThenReturn<S, R> thenReturn(Function<T, R> result) {
        if (matchingType()) {
            return new TerminalThenReturn<>(object, result.apply(castObject()));
        }
        return new ThenReturn<>(object);
    }
 
    public <R> ThenReturn<S, R> thenReturn(R result) {
        if (matchingType()) {
            return new TerminalThenReturn<>(object, result);
        }
        return new ThenReturn<>(object);
    }
 
    //...
 
}

Writing DSLs is much harder than using them, but it’s quite rewarding in the end. Notice how different return types are used (Then vs. ThenReturn) just to make sure only valid methods are accessible at each stage. An alternative is to implement run-time checks (for example that you don’t write is(...).is(...).then(...)) – but why bother if compiler can do it for us?

I hope you enjoyed this article, let me know if you are willing to try this utility in your project. It’s available on GitHub.
 

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

Leave a Reply

Your email address will not be published. Required fields are marked *

*


3 + five =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close