Groovy im Vergleich zu Java am Terminplaner-Beispiel

Ich habe den Terminplaner, den ich als Beispiel für testgetriebene Entwicklung programmiert hatte, von Java auf Groovy migriert. Für den Terminplaner in Java hatte ich testgetrieben ca. 180 Minuten benötigt. Für die Migration nach Groovy habe ich dann ca. 60 Minuten investiert.

Der erste Unterschied der Groovy-Lösung zur Java-Lösung ist der Wegfall der Klasse TeilnahmeStatus (war Enum bei Java). Die Teilnahme-Status-Informationen landen bei Groovy einfach in der Klasse Teilnahme.

Die equals- und compareTo-Methoden sind in Groovy einfacher zu implementieren, weil es für beides eigene Operatoren (== und <=>) gibt, die mit Null-Werten umgehen können.

Bei einer der compareTo-Methoden habe ich bei der Migrationen einen Fehler gefunden, der im Groovy-Code sofort offensichtlich wird. Im Java-Code kann man den Fehler durch die Klammerung beim flüchtigen Lesen übersehen (ist mir beim Schreiben der Java-Lösung ja offensichtlich auch passiert).

Die betroffene Java-Zeile sieht so aus:

int startZeitCompare = startZeit.compareTo(startZeit);

In Groovy wird der Problem sofort offensichtlich:

int startZeitCompare = startZeit <=> startZeit

Es muss natürlich heißen:

int startZeitCompare = startZeit <=> o.startZeit

Die Zahlen nach der Umstellung lesen sich so:

Java-Zahlen

• 5 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 37 Methoden inkl. Konstruktoren + 10 Methoden in Testklasse
  
• 246 LOC operativ + 144 LOC für Testklasse (inkl. Leerzeilen)
  
• 4 For-Schleifen, 4-If-Abfragen
  

Groovy-Zahlen

• 4 Fachklassen, 1 Exception-Klasse, 1 Testklasse
  
• 30 Methoden inkl. Konstruktoren + 9 Methoden in Testklasse
  
• 203 LOC operativ + 123 LOC für Testklasse (inkl. Leerzeilen)
  
• Alle 4 For-Schleifen wurden durch Closures ersetzt, die 4-If-Abfragen blieben bestehen.

Die Code-Ersparnis lässt sich im Wesentlichen auf folgende Groovy-Konzepte zurückführen:

• Closures machen For-Schleifen überflüssig und sind kürzer aufzuschreiben.
  
• Durch Properties werden Getter und Setter überflüssig.
  
• Typecasts entfallen.
  
• In den Tests spart die Uniformität von Arrays und Collections Konvertierungen.

In Groovy habe ich also ca. 80% der LOC (Lines of Code) benötigt, die ich für die Java-Lösung benötigte. Das hört sich erstmal nicht nach einem Quantensprung an. Allerdings muss man bedenken, dass ich „lediglich“ Java durch das doch sehr ähnliche Groovy ersetzt habe. Also hat eine Einzelmaßnahme 20% Code-Ersparnis gebracht. Setzt man das einfach mal naiv mit 20% Kostenersparnis gleich, ist man sehr schnell in Regionen, die interessant erscheinen (die meisten Offshoring-Untersuchungen sprechen von geringeren Einsparungspotenzialen).

Außerdem ist zu bedenken, dass mein Terminplaner-Beispiel die Strukturen in den Vordergrund stellt und die Daten ignoriert (so hat der Benutzer nur seinen Namen und der Termin nur 4 Datenfelder). In einer vollständigen Terminplaner-Anwendung sind viel mehr Datenfelder zu verwalten (MS-Outlook hat für Kontakte so um die 30 Datenfelder). Und gerade wenn es nur um das Halten von Datenfeldern geht, spielt Groovy seinen LoC-Vorteil aus. Die 30 Datenfelder würden in Groovy ca. 10 LoC bedeuten und in Java ca. 130 LoC (beide Zahlen inkl. Leerzeilen).

Nicht zuletzt habe ich die Terminplaner-Anwendung relativ stumpf auf Groovy umgestellt. Ich muss prüfen, ob sich der Code durch fortgeschrittene Groovy-Konzepte noch weiter vereinfachen lässt.

Der Groovy-Code findet sich hier zum Download.

Post bewerten