JAXenter

Software Frameworks sind aus dem heutigen Entwicklungsprozess kaum noch wegzudenken. Kein Wunder, treten sie doch mit einer Vielzahl von Versprechungen an, um die Welt der Softwareentwicklung effizienter zu gestalten. Dennoch ist ihr Einsatz nicht kostenlos: Bevor Frameworks effizient eingesetzt werden können, müssen Entwickler den Umgang mit ihnen zuerst einmal erlernen.

Um die Einarbeitung möglichst gering zu halten, stellen Framework-Entwickler verschiedene Dokumentationen zur Verfügung. Dennoch bleibt oftmals unklar, wie gewisse Anforderungen mit Hilfe des Frameworks erfüllt werden können. Wenn die bestehende Dokumentation keine Hilfestellung mehr geben kann, stellt der Quellcode anderer Programme, die das Framework bereits auf ähnliche Weise benutzt haben, eine interessante Informationsquelle dar. In diesem Artikel wollen wir anhand zweier Beispiele zeigen, wie IDEs ihre Nutzer beim Erlernen neuer Frameworks besser unterstützen könnten: beispielsweise, indem sie aus dem Quellcode anderer Anwendungen die korrekte Nutzung des Frameworks erkennen und dieses Wissen dem Entwickler wieder zur Verfügung stellen.

"IDE 2.0" – Wie geht das? Zwei Beispiele wie Code anderer Anwendungen Entwicklern helfen könnte.

Nehmen wir die folgende Situation als Beispielszenario: Ein Entwickler möchte mit den Frameworks SWT und JFace einen einfachen Eingabe-Dialog erzeugen. Innerhalb dieses Dialogs soll ein Benutzer über ein Textfeld eine Eingabe machen können, die vom System dann ausgelesen wird. Nehmen wir weiter an, dass der Entwickler bereits die korrekte Basisklasse (in unserem Fall die Klasse org.eclipse.jface.dialogs.Dialog) ausgewählt hat. Abbildung 1 zeigt den Code, den die Entwicklungsumgebung für den Entwickler initial bereit stellt.

Nachdem die ersten Zeilen generiert sind, stellen sich für den Entwickler zwei Fragen: Wo kann der Code für das Text-Widget platziert werden? Und wie muss das Text-Widget konfiguriert bzw. verwendet werden, damit der Code am Ende lauffähig ist und die Eingabe tatsächlich ausgelesen werden kann?

Beschäftigen wir uns zuerst mit dem Wo.

HotSpot-Identifikation der Klasse Dialog

Um erste Anhaltspunkte zu bekommen, welche Methoden der Basisklasse überschrieben werden müssen, wird zuerst die Javadoc-Klassendokumentation der Basisklasse nach Hinweisen untersucht. Im Fall der Klasse Dialog ist diese Untersuchung allerdings nicht sehr erfolgreich; die Klassendokumentation beschreibt lediglich das Konzept der "modalen Dialoge" (vgl. Javadoc View in Abbildung 1), gibt jedoch keinen Aufschluss darüber, wo der eigene Code eingefügt werden kann. Darüber hinaus gibt es in der Klasse auch keine abstrakten Methoden, die einen Entwickler auf die relevanten, da zu implementierenden Methoden hinweisen könnten. Der Entwickler ist jetzt also gezwungen, alle 55 Methoden von Dialog manuell zu untersuchen, d.h. nach interessant klingenden Methodennamen zu fahnden bzw. die Javadocs der Methoden auf entsprechenden Informationen hin zu analysieren.

Nun kommt die Frage auf, wie andere Entwickler die Klasse Dialog typischerweise erweitert haben, d.h. welche der 55 Methoden bisher von Entwicklern besonders häufig überschrieben wurden.

Würde der Entwickler den gesamten Code seiner Eclipse-Entwicklungsumgebung nach Dialog-Subklassen durchsuchen, käme er zu dem Ergebnis, dass fast alle Subklassen die Methode Dialog.createDialogArea() bzw. sehr viele Subklassen die Methode Dialog.okPressed() überschreiben. Diese Methoden scheinen also in besonderem Maße für Subklassen interessant zu sein – warum also nicht auch jetzt? Die spannende Frage lautet: Wieviel würde ein Entwickler davon profitieren, wenn ihm die IDE exakt diese beiden Methoden vorschlagen würde, anstelle der gesamten Liste – oder ihm zumindest eine Empfehlung geben könnte, welche der vielen Methoden er sich genauer anschauen sollte?