A method usually makes assumptions about the arguments that are passed into it by a method invocation. The conditions that the arguments must fullfil are named the method’s pre-conditions. Thus a good method implementation checks if the arguments are in an expected state so that the method can execute.

Often developers use basic data types as method parameters like String, Integer and so on, but a method usually doesn’t allow every possible value that these types can take. E.g. a method might declare an integer as parameter, but only accepts positive integers. Such a method might validate it’s pre-condition in this way:

Things will become more tricky the more parameters a method declares and even a lot more tricky if one parameter’s validation affects another. E.g.

More restrictive “primitive” types

Often a first attempt can be to introduce types that are more restrictive. E.g.

A method that declares such a parameter can be changed from

to

The more restrictive type approach is often usefull when using objects like String, because strings can take a lot of different values and it might be helpful to reduce the possible values that it can take. E.g. by introducing an EMail type that checks via a regular expression.

Pre-condition Duplication

The most simple pre-condition checks are also the ones that are usually duplicated. E.g. not null or positive integer checks.

To avoid pre-condition duplication you can use

 

Avoid Duplication using a utility class

Pre-condition duplications can often be prevented using a utility class with static methods. E.g.

So the code above would change to

As of Java 1.7 you can also use java.util.Objects. E.g

But a utility class also has disadvantages

  • Global Dependency
    Since the utility class is used all across the objects, the objects all depend on it. It is a global dependency and changing the utility class might affect every class.
  • Stack trace confusion
    Since the exception is thrown in the utility class the utility class is the first stack trace element and not the class that really took the arguments. The stack trace might confuse you more if the utility class itself delegates to other methods of itself.If the method itself throws the exception the stackstrace will look like this:

    compared to using a utility class

Avoid duplication using a parameter object

A parameter object is a design pattern the describes the usage of an object to represent parameters passed to a method.

The main concept of object-oriented programming is to bring logic and data together and the object can ensure that the data is in a leagal state at any time, because it controls the access to it.

In the case of method parameter validation it means that the validation logic belongs to the parameters. Thus the logic can be moved to a parameter object.

Dependent parameters validation

If 2 parameters belong together we can group them in an own object to make this relationship clear. Furthermore we can also validate the 2 parameter values if they depend on each other. E.g.

Optional parameters as properties

When using a parameter object we can also make clear by design which parameters are mandatory and which are optional.

Conclusion

My conclusion is that that using parameter objects is a good practice, because you can express a method’s pre-conditions in an object. A method can be sure that if the parameter object exists (not null) it is in a legal state so that processing can go on. Furthermore the parameter object moves most of the validation from the method that uses it to the client that invokes the method, because the client must create the parameter object.

Disadvantages only occur if you implement a method’s specific validation logic in a parameter object that you use accross different methods. In this case you make these methods depend on each other. As long as the validation logic only applies to the parameter object’s data itself (like the DataRange or PositiveInteger type above) you can safely use them accross multiple methods.

I have written an own blog that deals with this subject. The blog is about service layer designs, but parts of it applies to other design problems too. Take a look at Pros and cons of service layer designs, especially the section Dedicated request and response types per service method.