Home » Java » Core Java » Avoiding Many If Blocks For Validation Checking

About Patroklos Papapetrou

Patroklos Papapetrou
Patroklos is an experienced JavaEE Software Engineer and an Agile enthusiast seeking excellence in software quality. He is also co-Author of the Sonar in Action book, and contributor of several Sonar plugins.

Avoiding Many If Blocks For Validation Checking

There are cases that we want to validate input data before we send them to business logic layer for processing, computations etc. This validation, in most cases, is done in isolation or it might include some cross-checking with external data or other inputs. Take a look at the following example that validates user input for registration data.

public void register(String email, String name, int age) {
 + "[A-Za-z0-9-]+(\\.[A-Za-z0-9]+)*(\\.[A-Za-z]{2,})$";
 Pattern pattern = Pattern.compile(EMAIL_PATTERN);
 List<String> forbiddenDomains = Arrays.asList("domain1", "domain2");
 if ( email == null || email.trim().equals("")){
   throw new IllegalArgumentException("Email should not be empty!");
 if ( !pattern.matcher(email).matches()) {
   throw new IllegalArgumentException("Email is not a valid email!");
 if ( forbiddenDomains.contains(email)){
   throw new IllegalArgumentException("Email belongs to a forbidden email");
 if ( name == null || name.trim().equals("")){
   throw new IllegalArgumentException("Name should not be empty!");
if ( !name.matches("[a-zA-Z]+")){
   throw new IllegalArgumentException("Name should contain only characters");
if ( age <= 18){
   throw new IllegalArgumentException("Age should be greater than 18");
// More code to do the actual registration

The cyclomatic complexity of this method is really high and it might get worse if there are more fields to validate or if we add the actual business logic. Of course we can split the code in two private methods ( validate, doRegister ) but the problem with several if blocks will be moved to the private methods. Besides this method is doing more than one thing and is hard to test. When I ask junior developers to refactor this code and make it more readable, testable and maintainable they look at me like an alien :”How am I supposed to make it simpler. How can I replace these if blocks?” Well here’s a solution that works fine, honors the Single Responsibility Pattern and makes the code easier to read.

To better understand the solution, think each of these if blocks as a validation rule. Now it’s time to model these rules.

First create an interface with one method. In Java 8 terms, it’s called a functional interface, like the following.

public interface RegistrationRule{
 void validate();

Now it’s time to transform each validation check to a registration rule. But before we do that we need to address a small issue. Our interface implementation should be able to handle registration data but as you see we have different types of data. So what we need here is to encapsulate registration data in a single object like this :

public class RegistrationData{
 private String name;
 private String email;
 private int age;
// Setters - Getters to follow

Now we can improve our functional interface:

public interface RegistrationRule{
void validate(RegistrationData regData);

and start writing our rule set. For instance let’s try to implement the email validation.

public class EmailValidatationRule implements RegistrationRule{
 private static final String EMAIL_PATTERN = 
 + "[A-Za-z0-9-]+(\\.[A-Za-z0-9]+)*(\\.[A-Za-z]{2,})$";
 private final Pattern pattern = Pattern.compile(EMAIL_PATTERN);
 public void validate(RegistrationData regData) {
 if ( !pattern.matcher(regData.email).matches()) {
   throw new IllegalArgumentException("Email is not a valid email!");

It’s clear that we have isolated in the above class the email validation. We can do the same for all rules of our initial implementation. Now we can re-write our register method to use the validation rules.

List<RegistrationRule> rules = new ArrayList<>();
 rules.add(new EmailValidatationRule());
 rules.add(new EmailEmptinessRule());
 rules.add(new ForbiddenEmailDomainsRule());
 rules.add(new NameEmptinessRule());
 rules.add(new AlphabeticNameRule());
 for ( RegistrationRule rule : rules){

To make it even better we can create a Rules class using the Factory pattern and a static method get() that will return the list of rules. And our final implementation will look like this

for ( RegistrationRule rule : Rules.get()){

Comparing the initial version of our register method to the final one leaves room for doubts. Our new version is more compact, more readable and of course more testable. The actual checks have been moved to separate classes (which are easy to test also) and all methods do only one thing (try to always keep that in mind).

Reference: Avoiding Many If Blocks For Validation Checking from our JCG partner Patroklos Papapetrou at the Only Software matters blog.
(0 rating, 0 votes)
You need to be a registered member to rate this.
6 Comments Views Tweet it!
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 our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

5 Comment threads
1 Thread replies
Most reacted comment
Hottest comment thread
6 Comment authors
Nilesh DabholkarUffeMarcelAndrey Radramesh Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

newest oldest most voted
Notify of

This is a good example to have a maintainable and test friendly coding fashion for same old problem. Every developer come across such situation when they don’t like a bunch of ‘if’s but though have to have it.
Thanks for the share.



TO reduce the number of if else blocks , we are creating the related classes which contains the functionality of validation , but these leads to increase in the number of classes , as per your design each validation / field leads to one class. is it fine having like this ?

Andrey Rad
Andrey Rad

I think that it could be more useful to put rules to array in some enum Rules. So you could manage rule’s collection independenly from validator code. And additionally you could use different rule’s set for different life cycle like CREATE, UPDATE and so on.

By the way… You could do more… You could get all rules that you need as
@Inject @SOMEGROUP private Instance rules;

We used this approach for checking a lot of xml orders with huge numbers of validation rules.


Hi, this is a nice example on how to make simple things complex without any reason.

The first version is perfectly readable (without any code jumps), easy to debug and really error unresponsive, no matter if you are a junior or a senior developer.

If there are no other unnamed circumstances I would definitely reject such a “refactoring” commit. I usually would prefer to have models instead of Strings which could handle validation but this doesn’t seem to fit here.

I don’t want to point at questions like performance or memory (you didn’t specify the rules List static).


Good points, Marcel.
Other suggestions:
* we could obviously put the validation in a validate() method.
* or generalize and create a helper class with common validation routines:
public class ValidationHelper{
public static void validateEmail( String email, String errorMessage ){ … }
public static void validateNotContains( String str, String substring, String errorMessage){ … }
public static void validateNotEmpty( String str, String errorMessage ){ … }


Nilesh Dabholkar
Nilesh Dabholkar

Great example of simplifying the code and improve its legibility. I would go a step further and use Chain of Responsibility pattern instead of a List and a for loop