Boilerplate adé: Project Lombok

Ausgangspunkt: Boilerplate

Boilerplate Code ist dieser hässliche Begriff, bei dem die Haare eines jeden Entwicklers zu Berge stehen.
Mit der Bezeichnung sind Code Blöcke gemeint, die immer und immer wieder in leicht abgewandelter Form auftauchen.

In Java sieht man häufig Klassen die wie folgt aussehen:

public class Customer {
  private long id;
  private String name;

  public Customer() {}
  public Customer(long id, String name) {
    this.id = id;
    this.name = name;
  }
  
  public long getId() {
    return this.id;
  }
  
  public String getName() {
    return this.name;
  }

  public void setId(long id) {
    this.id = id;
  }

  public void setName(String name) {
    this.name = name;
  }

  @Override
  public String toString() {
    return "Customer{id:" +this.id + ", name:" + this.name + "}"
  }
}

Erweitert man die Klasse nun auch noch um die Überschreibung von equals() und hashCode() wird die Klasse noch länger. Für jede Objektvariable fügen wir also mindestens 6 Zeilen Boilerplate Code zu unserem Programm hinzu.
Es entsteht sehr viel Code, der wiederum einen sehr geringen Informationsgehalt vorweist.

Kein Wunder also, dass viele Entwickler die Erstellung von Gettern und Settern der IDE überlassen.

Was passiert jedoch, wenn wir folgenden Changerequest erhalten?

[…] wir müssen dringend statt des Namens, den Vornamen und den Nachnamen getrennt erfassen! […]

Okay. Kein Problem! Wir benennen einfach die Objektvariable name in firstName um und fügen zusätzlich die Variable lastName hinzu.

Soweit so gut. Die meisten IDE’s verfügen über mächtige Refactoring-Tools, sodass beim umbenennen der Variable name zu firstName auch die Getter und Setter angepasst werden.

Doch was ist mit lastName? Wir brauchen noch einen Getter und einen Setter für diese Variable. Noch etwas vergessen? Achja! Die toString() Methode muss natürlich auch angepasst werden. Jetzt aber. Nein, die hashCode Methode müssen wir auch noch einmal anfassen und zum krönenden Abschluss auch noch die equals Methode.

Hier ist eine Menge Fehlerpotential am Werk und genau hier kommt auch Project Lombok ins Spiel.

Project Lombok

Die gleiche Klasse von oben sieht mit Lombok wie folgt aus.

@Data
  @NoArgsConstructor
  @AllArgsConstructor
  public class Customer {
    private long id;
    private String name;
  }

Lombok generiert nun zur Compile-Zeit sämtliche Getter und Setter, die toString- equals und hashCode Methoden, einen Konstruktor ohne Argumente sowie jeweils einen Konstruktor mit allen notwendigen und einen mit allen verfügbaren Argumenten.

Lombok generiert ausschließlich Getter / Setter, die noch nicht vom Nutzer implementiert wurden.

@Data
  @NoArgsConstructor
  @AllArgsConstructor
  public class Customer {
    private long id;
    private String name;

    public void setName(String name) {
       if(name.equals("foo-bar") {
         this.name = name;
       }
    }
  }

Einen solchen Setter wird Lombok also nicht überschreiben.

Lombok Features

Lombok verfügt, neben dem generieren von Gettern und Settern, noch über einige weitere sehr nützliche Features.

• Mit @Builder wird automatisch eine statische Builderfunktion für die jeweilige Klasse erzeugt
• Eine Collection mit @Singular annotieren und es wird eine Funktion generiert, die es ermöglicht einzelne Objekte einer Collection hinzuzufügen
• @Log (konkrete Log-Frameworks stehen hier) und die Initialisierung von Loggern hat ein Ende!

Die gesamte Feature Liste kann hier in der Dokumentation nachgelesen werden: https://projectlombok.org/features/all

Lombok Installation

Um Lombok in euren Projekten verwenden zu können, werden zwei Dinge benötigt:

• Einen Eintrag für Lombok in eurer Maven/Gradle Datei
• Ein Plugin für eure IDE

Je nachdem welches Buildtool Ihr nutzt sind hier einige Links:

• Gradle
• Maven
• Ant

Das Plugin für eure IDE wird auf unterschiedliche Art und Weise installiert.

• IntelliJ
• Eclipse
• Netbeans

Resümee

Ich bin sehr angetan von Lombok. Die Reduzierung von Boilerplate Code und damit das Entfernen von Fehlerpotentialen, ist für mich eines der Hauptvorteile. Darüber hinaus ist die Art und Weise, wie die Klassen annotiert werden, meiner Meinung nach, sehr ausdrucksstark und lesbar.
Das einzige Manko: Für den Einsatz ist ein Plugin zwingend erforderlich. Möchte ein Team also im Projekt Lombok einsetzen, müssen alle ein zusätzliches Plugin installieren. Diesen Punkt halte ich aber durchaus für verkraftbar.

Lob, Kritik, Anregungen?

Wir freuen uns auf Ihre Meinung