Das Buch “Groovy in Action” führt den Begriff “Beauty through Brevity” ins Feld, der auch gern in Verbindung mit Scala oder Clojure einhergeht. Lässt man diese Sprachen für sich alleine mag das auch gelten, doch für viele Entwicklungen, die noch mit älterem Java-Code arbeiten, ist es wichtig, dass die Kombination verschiedener Sprachen ein stimmiges Gesamtbild abgibt – und hier lauern gern die ein oder anderen Stolperdrähte.
Unter https://github.com/Zigu/PdfRenderer habe ich ein älteres Projekt von mir in ein neues “Misch-Gewand” geworfen und geschaut ob es funktioniert. Und ja, das tut es – mit Einschränkungen.
Grundsätzlich kann man sagen, dass die Kombination Maven2 + Java + Groovy eine sehr angenehme Sache ist, wenngleich der Weg dorthin etwas dornig war. Insbesondere durch die maßlos veraltete Dokumentation von GMaven – ich verzichte bewusst auf eine Verlinkung – wodurch nicht klar war, wie einfach es eigentlich ist Maven dazu zu bringen auch Groovy-Code zu verarbeiten.
Vorsicht ist allerdings geboten beim Einsatz von Closures in Vererbungshierarchien. Es gibt in Groovy 1.7.6 noch ein Problem, wenn eine konkrete Kindklasse aufgerufen wird, deren abstrakte Oberklasse ein Closure enthält, dass private Felder dieser Elternklasse verwendet. Eine kurze Skizzierung des Problems:
abstract class A {
private List _myList;
private ListElementHandler _handler;
public void handleList() {
_myList.each{ _handler.do_something_with(it) }
}
}
class B extends A { ... }
class C {
public void call() {
def b = new B()
b.handleList()
}
}
Leider kommt es im Zuge des Abarbeitung der Klasse C zu einer Exception, dass das Feld _handler nicht zur Klasse B gehört. Dieses Problem ist bereits in den Groovy-Bugtracker aufgenommen worden.
Trotz dieser kleineren Hürden, verlief die Umstrukturierung ziemlich glatt und am Ende entstand größtenteils ein stimmiges Gesamtbild mit einigen sehr angenehmen “Abkürzungen” dank Groovy.
Clean Code stellt viele Aspekte für unschönen Code vor, die man bei der täglichen Arbeit zwar bemerkt, aber bei denen man unter Umständen nicht immer weiss wie man sie besser machen kann. Der Autor gibt sich hierbei nicht den Anspruch des allumfassenden “So-und-nicht-anders”, sondern lässt Freiraum für eigene Entscheidungen.
Martin Fowler stellt verschiedene Refactoring-Mechanismen vor und erklärt die Motivation, die hinter jedem einzelnen steckt. Da es sich hierbei u.a. auch um sehr triviale Refactorings handelt, wirkt das Buch zeitweise etwas trocken.
Ähnlich aufgebaut wie das “Refactoring”-Buch werden hier verschiedene Code-Probleme anhand einfacher Beispiele erklärt und deren Lösung durch Patterns oder in Richtung eines Patterns vorgestellt.