Here is an example of creating a fluent builder interface for invoking a method via Java Reflection. While the code to invoke Java methods via reflection is not complex, it can be improved. We can introduce a ‘façade’ and this façade can use the fluent builder pattern. Of course, doing all this just to invoke a method is not the point, but to illustrate or experiment with the pattern.
One example of using this is:
Or in prose, this is what the above is doing: Invoke method name “greet”, on object anObject, with the argument “Hello world!”, of class types String.class. Note that some of the words in the prose were used as the method names. Fluent Interface is somewhat of a mini Domain Specific Language (mDSL).
The final invoke() will use the information and generate whatever is required in order to perform the method invocation. More on this later.
Fluent Interfaces (not just about chained setters) are an old concept that is becoming more well known and used. One popular blog post was FluentInterface by Martin Fowler. Since then there are many resources on this.
The main motivation was the issues with current practices in creating interfaces. In Item 2: Consider a builder when faced with many constructor parameters by Joshua Bloch, the disadvantages in “Telescoping constructors” and the JavaBean pattern are analyzed and why a builder may be more useful.
I wanted to learn more about this, so I wanted an approachable application, but not too easy. Reflective invocation of a method is very doable. Currently, you must find a Method, then invoke with the correct arguments. But, all this is kind of kludgy, for example the Method‘s invoke method is
We create a fluent interface that combines the Method look up and the invocation on an object into a Facade. Then the invoke method of the builder will perform the actual invocation and it will use whatever is available to properly perform this.
In more complex situations, a builder can employ various techniques to create the final object or invoke the desired action. One technique is to execute a Decision Table.
One complication is that I wanted this to be usable as a static utility class. Thus, a static method of the utility class will create a nested class that implements the builder pattern.
Source code available at gist: https://gist.github.com/josefbetancourt/3ffcb3044e558fc1b3e8
The list of “verbs” is:
- name: what is the method name?
- on: on what object or class to invoke?
- of …: types of arguments?
- using …: using what parameters?
- nosy: is method private?
- method: use a known method object?
- clazz: instead of method what class?
- returning: what type of object to return?
- invoke: Invoke by figuring out what to do.
Of course, not all of these are required to invoke a method, not even a target object, since a static method can be invoked on a class.
An example use is:
Presented was an easy example of the start of a possible Fluent Interface for a utility. One problem though, is that the invoke method will attempt to invoke with what was supplied by the developer. In a more complex application of the Fluent Interface this can lead to run-time exceptions if this is not done correctly, or if the invoke or build method is not up to snuff. An interesting pattern Step Builder pattern by Marco Castigliego addresses some of the shortcomings of a pure Fluent Builder pattern. In the Step Pattern the steps, guided by interfaces, “guides” the creation of the object or action.
- The Builder Pattern in Practice
- Item 2: Consider a builder when faced with many constructor parameters by Joshua Bloch
- FluentInterface by Martin Fowler
- Fluent Interface at Wikipedia
- Step Builder pattern by Marco Castigliego
- Building smart Builders
- Fluent Interface and Reflection for Object Building in Java
- IllegalAccessException is not a SecurityException by Cheng Fang
- Method Chaining
- How to build a basic fluent interface in 8 steps by Jorge Rowies
- The Java Fluent API Designer Crash Course by lukaseder
March 4, 2013, 22:07: Now that I finished the above learning exercise, I wanted to find out how others did something similar. So far, found the FEST which has a Fluent Reflection module. So, I wasn’t off to a bad start, but FEST is more comprehensive! An interesting post by Alex Ruiz is: Fluent interfaces: don’t chain for the sake of chaining
- Java Properties dupe key detect using subclass
- Use truthy falsy booleans in Java
- Java reflection on a message using MethodHandle
- Java Properties dupe key detect using CGLIB
- Java Properties dupe key detect using Javassist