I am a software developer from Poland, currently working in banking industry. For the past few years I have been writing software in Java, however I actively seek for a close alternative. Certified in SCJP, SCJD, SCWCD and SCBCD, used to be active on StackOverflow. I feel comfortable at the back-end, however recently rediscovered front-end development. In spare time I love cycling. Tomasz is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

instanceof Operator and Visitor Pattern Replacement in Java 8

10.05.2013
| 10635 views |
  • submit to reddit

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.

Published at DZone with permission of Tomasz Nurkiewicz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Hendy Irawan replied on Sat, 2013/10/05 - 4:47am

Awesome !

However it'd have been much better if Java8 took Scala's pattern matching, at least this useful subset into it.

Oh well....

BTW your library should be integrated into Google Guava. Any chances you'd propose?

Tomasz Nurkiewicz replied on Sun, 2013/10/06 - 7:53am in response to: Hendy Irawan

Thanks for your comment. I love Guava but it currently targets Java 8. When it will require Java 8, a lot of Guava will be deprecated or obsolete.

Oliver Plohmann replied on Mon, 2013/10/07 - 3:34pm

 Hi Tomasz,

always enjoying your posts about JDK8, especially this one. Amazing what you can do with some understanding of closures :-). Awesome, really.

When it will require Java 8, a lot of Guava will be deprecated or obsolete. Same thing with Spring ...

-- Oliver

Kris Nuttycombe replied on Wed, 2013/10/09 - 1:59pm

This unfortunately misses the main purpose of using the Visitor pattern - that is, you get compiler-enforced totality checking. A Visitor defines a closed set of constructors (in Java, subtypes) for a type, and to define a Visitor for that set you must address all of those constructors. I wrote about this a bit here: http://logji.blogspot.com/2012/02/correcting-visitor-pattern.html

Raging Infernoz replied on Sun, 2013/10/13 - 8:14am

This looks clever, but is dubious, because it will likely sabotage compiler and run-time Hotspot optimisations, and will make debug harder.  I detest Spring and other over abstracted frameworks like Hibernate for similar reasons.

I suggest people are very careful using this because it could result in worse code than simpler approaches.

Raging Infernoz replied on Sun, 2013/10/13 - 8:30am in response to: Oliver Plohmann

He is playing with fire; I do concurrent code, I know the traps, his users may not!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.