Daniel Gazineu

A DSL for validations using fluent interfaces

As a software developer, I’m particularly interested in Domain Driven Design (DDD) and Domain Specific Languages (DSL). In the last few weeks I’ve been flirting with Fluent Interfaces and trying to get used to its techniques in order to apply it to build better DSL for my domains.

During my studies, I decided to build a small validation framework with a fluent interface to put in practice what I’m reading. It’s far from being ready for professional usage but its development is being a good exercise with fluent interfaces and DSL.

What I was looking for in the beginning of its creation was something to enable the developer to make validations in a more human friendly way.

Let’s say you have an object called ‘myObject’. How would you ask to a validation framework to ensure it is not null?
Well, I made this question to myself and one of the possible answers was:

“Ensure myObject is not null.”

This part was pretty easy to implement and the first draft of the Fluent Validation Framework (as I call it) looked like this:

ensure(myObject).isNotNull();

But at the same time that I would like to build something as simple as:

ensure(myObject).isEqualsTo(myOtherObject);

I also wanted to have more control of the result of the validation. Something like:

ensure(myObject).isNotNull().otherwise(“myObject cannot be null”);

Or even better:

ensure(myObject).isNotNull().otherwise()
                            .throwThis(new IllegalStateException());

In both examples above we can see a problem inherent to the Method Chaining technique. It’s not possible to know during the execution of isNotNull() method that there is another method to be executed after it, this way, using this approach, it would be necessary to add an execution command at the end of the chain:

ensure(myObject).isNotNull().otherwise()
                            .throwThis(new IllegalStateException())
                            .now();

This works, but lets our DSL too extensive. A simple null verification would be:

 ensure(myObject).isNotNull().now();

Moreover, I didn’t like this now() method in the end of the sentence, it’s not so fluent and intuitive.
This way, I decided to move to the Nested Function approach. After some rethinking, the API usage for the same situations listed above was:

ensure(myObject).is(notNull(), otherwise(
                                   throwThis(new IllegalStateException()));

Also, the short validation would work with few parameters:

ensure(myObject).is(notNull());

This brings a good side benefit: passing the validation as a parameter to is(Condition) method enables the developer to create his own validation conditions and extend the framework to work with his domain. In the other hand, I added more necessary static imports to the code, otherwise, the code would be:

Validator.ensure(myObject).is(Conditions.notNull(),
                              Actions.otherwise(
                                  Actions.throwThis(
                                      new IllegalStateException()));

Too much code for a simple if/else block. Moreover, this verbose code doesn’t seem to be so human oriented.

After thinking for a while, I fingered you that the technology problem I was facing could be solved by a linguistic review of the solution. It’s right that an easy way to ask a framework to validate something is saying:

Ensure myObject is not null, otherwise, throw this exception.

But it can also be said:

Analyze myObject and throw this exception if it’s null.

This way, I achieved the following result:

ensure(myObject).isNotNull();

or:

analyse(myObject).and().throwThis(new IllegalStateException()).ifNull();

Moreover, this solution uses internally the methods is(Condition), ifIsNot(Condition) and and(Action), what enables developer to create his own conditions and actions:

ensure(myObject).is(inValidState());

or:

analyse(myObject).and(logAnError()).ifIsNot(inValidState());

Assuming that methods inValidState() and logAnError() were created by the developer and return a Condition and an Action respectively.

My idea is to improve this framework adding specific validations for Strings, Numbers, Arrays and Collections, letting specific domain validations to be built inside their domains.

Soon I’ll be posting and discussing this code here, but now it’s time to sleep!