Stop writing obvious code for POJOs, use lombok’s @Data

Lombok helps in getting rid of the obvious code that we write when we define a class, instead it generates the obvious code at the time of compilation. Lets say if you are writing a plain vanilla bean to define a Car that has three attributes make, model and year you will define a class with these three variables and will define a no-argument constructor, setters and getters for all the variables. For any bean or POJO that you define, isn’t this code obvious that you always write? What if an annotation can generate all this code for you and you just define the class and its member variables.

The below screen shot of eclipse shows the java code for the class Car on the left side and the outline on the right side. It can be observed that the class definition doesn’t have the getters/setters, constructor or the other methods but the outline has them. The code is generated by the @Data annotation provided at the class level. The code looks amazingly precise.

Lombok Data
Class definition and methods generated by Lombok

Apart from the getters/setters, equals, hashcode and the constructors, @Data also generates a canEquals method; this checks if the given of the same type, precisely it performs instance of check. toString generates the string representation of the object in the format, classname(var1=valueofvar1 var2=valueofvar2 ... varn=valueofvarn) where var1 … varn are member variables of the class.

If a class has final variables, @Data generates a constructor with all the require arguments. For example, if you have a class like below,
@Data
public class CarWithFinalVariable {
private final String make;
private String model;
private int year;
}

lombok generates a constructor, public CarWithFinalVariable(String make)
When using lombok, I personally advice not to write additional constructors or methods inside a POJO. You may write one or more setter of you have to impose certain restrictions but for constructor it is strict NO NO. One should never write a code like below
@Data
public class CarWithFinalDontDoIt {
private final String make;
private String model;
private int year;
public CarWithFinalDontDoIt() {
make = null;
}
}

The no argument constructor here kills the purpose of the final variable, and eventually misguides the users of this class.

One of my favorites is toString because I don’t want to put my efforts in writing a method that serves no business purpose at the same time while debugging, when I hover the mouse over a variable I feel convenient to see the state of the object rather than seeing the object id and then go and expand to see the state. It is possible to configure the toString so as exclude the variables that you feel are trivial. Below is the example of excluding the variable make from toString
@Data
@ToString(exclude = "make")
public class CarConfigureToString {
private String make;
private String model;
private int year;
}

further reading
github url

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s