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 two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


six − 4 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

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

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close