Code Practise - Validators

You would probably not say this when you look at the state of my desk, but I enjoy working in a clean environment. For me, this translates into a desire to have a clean codebase.
In a previous post I have talked about the redesign I am doing on my pet project “TraMBU”. Other that entire reworks of projects, I really enjoy the feeling of figuring out a clean way of implementing something.

Cleaning Code

As a developer, I am often amazed by how elegant and well-designed some libraries I commonly work with are. A prime example of this is the Spring Framework. The Lady Java parody song claims “I want to program like they do at Oracle”. This desire holds true for me in some way. I’d like to arrive at the point where I am able to write code that is just as elegant as most of the code that the guys over at spring.io write.

In order to one day get to that point of mastery, I tend to think about design and code style a lot. Recently at work, we were tasked with writing a validator that checks whether the internal state of a domain object is sane. In the past, I have usually done this by writing a big validate method that in turn calls a bunch of private methods, each validating a certain aspect of the state of the object.

Validator

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package validation;

import java.util.ArrayList;
import java.util.List;

public class OldStyleStringValidator {

  public boolean isValid(String testString) {
    return this.validate(testString).isEmpty();
  }

  public List<String> validate(String testString) {
    List<String> errors = new ArrayList<>();

    if (isEmpty(testString)) {
      errors.add("Input may not be empty");
    }

    if (containsBadWord(testString)) {
      errors.add("Input may not contain the F word");
    }

    return errors;
  }

  private boolean containsBadWord(String testString) {
    return testString != null && testString.toUpperCase().contains("FUDGE");
  }

  private boolean isEmpty(String s) {
    return s == null || s.length() == 0;
  }
}

The validators I have written before all look something like the code snippet above. In general, I like validators to return a List of error messages explaining what is wrong with the object under test. Since sometimes you just want to know whether or not it is valid, there is also a isValid() method that just checks if the error message List is empty. You could save the error messages as a class variable in the Validator class, to avoid recalculating the error messages multiple time. However, my experience teaches me that when other people use your code, they tend to not create new objects for every new validation run. This could result in some weird state-issues, if not handled correctly internally in the Validator class. Obviously, this adds more clutter to the code.

My somewhat cleaner solution

Making use of some of the nice functional options we have gotten in Java 8, I was able to rewrite these validators to be a lot more concise and readable. You can find the result below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

package validation;

import java.util.List;

public class StringValidator extends Validator<String> {

  @Override
  public List<String> validate(String toValidate) {
    return new ValidationResult<>(toValidate)
        .validationStep(this::isNotEmpty, "Input may not be empty")
        .validationStep(this::doesNotContainBadWord, "Input may not contain the F word")
        .getValidationErrors();
  }

  private boolean isNotEmpty(String s) {
    return s != null && s.length() > 0;
  }

  private boolean doesNotContainBadWord(String s) {
    return s != null && !s.toUpperCase().contains("FUDGE");
  }
}

This class extends the abstract superclass Validator.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

package validation;

import java.util.ArrayList;
import java.util.List;
import java.util.function.Function;

public abstract class Validator<T> {

  public abstract List<String> validate(T toValidate);

  public boolean isValid(T toValidate) {
    return this.validate(toValidate).isEmpty();
  }


  protected class ValidationResult<T> {

    private final T toValidate;
    private List<String> validationErrors = new ArrayList<>();

    public ValidationResult(T toValidate) {
      this.toValidate = toValidate;
    }

    public ValidationResult<T> validationStep(Function<T, Boolean> validIf, String errorMessage) {
      if (!validIf.apply(toValidate)) {
        this.validationErrors.add(errorMessage);
      }
      return this;
    }

    public List<String> getValidationErrors() {
      return validationErrors;
    }

    public boolean isValid() {
      return this.validationErrors.isEmpty();
    }
  }
}

The validators can make use of the internal ValidationResult class, that is used to be able to chain different method lambda’s together. This way the code in the concrete validator is concise, readable, and just the right amount of expressive. I have also decided that I want to express when an object is valid, in stead of when it is invalid. You can see this in the chaining validationsteps in the concrete class. When you read it top to bottom, you get a pretty good idea of what a String must adhere to, in order to pass our validation process.

I am actually pretty proud of my solution, so I wanted to share it with you guys. I hope you enjoyed it, or at least picked up a few ideas that you could use.