Andreas gab mir kürzlich den Tipp eine nette Bibliothek anzusehen: lombok . Lombok erweitert den Java Kompilierungsvorgang, so daß bestimmte Klassen mit weniger unnötigem Code auskommen da dieser bei der Kompilierung erzeugt wird.
Ich bin total begeistert, so reicht es aus @Data an eine Klasse zu schreiben und schon werden die getters und setters, toString() und die hashCode() und equals() Methoden generiert. Im Prinzip funktioniert das so wie die magischen Methoden in Groovy. Ich mag das, da ich mich mehr auf die wichtigen Methoden kümmern kann ohne mich durch hunderte von unnötigen Zeilen scrollen zu müssen. Ich mag auch, daß so niemand Getter oder Setter für Seiteneffekte missbrauchen kann. Es passt auch in den agilen Prozess: Es beseitigt muda .
@SneakyThrows ist genial! Ich hasse die UnsupportedEncodingException auch wenn ich klar „UTF-8“ spezifiziere, welches garantiert immer vorhanden ist.
Vor allem mag ich den Implementationsansatz: Lombok hängt sich in den Kompilationsvorgang und generiert den entsprechenden Code für die Annotations. Das Eclipse Plugin sorgt dafür daß Eclipse diese (nicht im code vorhandenen) Methoden anzeigen kann.
Lombok ist cool und ich hoffe es wächst weiter.
Aber leider ist die Lombokmagie schwer zu verstehen. Im Code findet sich keine Erklärung dafür wie die Klasse zur Laufzeit sich verhalten wird. Dafür, daß der Code letztendlich nur etwas aufgeräumt wird, muss der durchschnittliche Entwickler viel lernen.
Man denke auch an die Wartung: Wenn man jetzt Lombok verwendet und in 2 Jahren niemand mehr von Lombok spricht, weil das Projekt tot oder nicht mehr cool ist, wer soll dann ein weiteres Jahr später den Code warten können? Man wird sich wundern wie der Code funktionieren konnte, kompiliert er doch ohne Getter und Setter nicht mehr.
Anmerkung zu Gettern und Settern: I glaube man benötigt sie eigentlich gar nicht, sondern generiert sie nur weil Framework X sie braucht. Getter und Setter sollten keine unerwarteten Seiteneffekte haben. Also genau so wie sie Lombok generiert. Doch dann stellt sich die Frage warum man diese Methoden überhaupt braucht und die Felder nicht einfach public macht. Ich denke der Grund ist der, daß man in Wirklichkeit keine Getter und Setter auf Felder braucht, sondern eigentlich Domänenmethoden haben möchte. Ganz einfach ohne unnötige Getter und Setter und ohne Lombok 🙂
Lombok ist definitiv ein netters Spielzeug für erfahrene Entwickler. Und es ist auch sehr mächtig mit einer erkennbar guten Tendenz für zukünfigie Entwicklungen. Für private Projekte werde ich es sicher nutzen.
Was denkt Ihr über das Verhältnis von Nutzen zu Verwirrung. Ist es vielleicht sogar konstant, so daß jeder Nutzen immer Verwirrung bringt?
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.