If Fase Logo

mit Google im Archiv der If Fase

Ausgabe 4 vom 1. November 2005 (als PDF):

3. Oktober 2005 – Thomas Hammersen

Delphi als geeignete Entwicklungsumgebung für Anfänger?

Erfahrungen eines Referendars

Ich bin seit etwa 20 Monaten Referendar und habe seit dem nahezu täglich Schüler beobachtet, die mit der Entwicklungsumgebung Delphi arbeiten. Neben den zahlreichen Vorteilen dieser Umgebung – es ist erstaunlich, wie schnell sich eine Programmoberfläche erzeugen lässt – sind mir dabei auch einige Nachteile aufgefallen, die ich im Folgenden kurz beschreiben möchte.

Man stelle sich etwa die nicht allzu weit hergeholte Situation eines Schülers vor, der ein Eingabefeld für sein Formular deklarieren möchte, um Benutzereingaben verarbeiten zu können. Um dies zu erreichen, fügt er seinem Standardformular mittels der Zeile 'Eingabe : TEdit;' ein entsprechendes Attribut zu – genau so, wie er es in den ausgedruckten Musterlösungen seines Lehrers schon mehrfach gesehen hat. Wenn er das Programm jedoch startet, wird er mit der folgenden Fehlermeldung konfrontiert:

Fehlermeldung von Delphi

Delphi hält es offensichtlich für abwegig, dass der Schüler an dieser Stelle nicht seine obige Deklaration entfernen, sondern stattdessen lieber eine entsprechende Komponente in sein Formular aufnehmen möchte. Zugegeben, hätte er eine Eingabefeldkomponente hinzufügen wollen, hätte er ja einfach seine Maus in die Hand nehmen, den Quelltexteditor per Klick minimieren, in der Menüleiste unter den (in der Version 7) 33 Reitern denjenigen mit dem Eingabefeldsymbol auffinden und anklicken, das Startformularfenster per Klick öffnen, auf diesem per Klick ein Eingabefeld platzieren, im Objektinspektor durch Scrollen nach der Eigenschaft 'Name' suchen, in das nebenstehende Eingabefeld klicken, die Tastatur in die Hand nehmen, den Standardnamen 'Edit1' durch einen sinnvollen Namen (hier: Eingabe) ersetzen, die Maus in die Hand nehmen, den Quelltexteditor anklicken und die Tastatur zur weiteren Bearbeitung in die Hand nehmen müssen. Dann hätte er sich die ganze Tipparbeit (die Textzeile 'Eingabe : TEdit;' wurde inzwischen automatisch von Delphi eingefügt) und die obige Fehlermeldung erspart.

Die Folgen des obigen Szenarios sind offensichtlich: Erstens sind die Schüler verunsichert, wenn ein und dieselbe Pascal-Datei gleichzeitig funktionieren kann oder auch nicht. Zweitens suchen die Schüler ihre Fehler künftig nicht mehr im eigenen Programmcode, sondern vermuten (erneut) ein rätselhaftes Verhalten der Entwicklungsumgebung. Drittens führt der ständige Wechsel zwischen Maus und Tastatur dazu, dass die Schüler obigen Prozess dahingehend abkürzen, dass sie sich mit den von Delphi vorgeschlagenen Standardnamen für Komponenten (wie z.B. Edit1) zufrieden geben. Nicht selten habe ich erlebt, dass Schüler, die innerhalb eines Programms mehrere Eingabefelder mit den Standardnamen Edit1, Edit2 usw. angelegt haben, die Bedeutung der einzelnen Eingabefelder verwechselt und somit unnötig lange nach den sich daraus ergebenden Laufzeitfehlern gesucht haben.

Es scheint nicht zu den Zielen der Entwickler von Delphi zu zählen, dieses Programm ausschließlich mit der Tastatur bedienen zu können. Als sich ein Schüler einmal aufgrund einer fehlenden Mauskugel auf dieses Experiment einlassen musste, gab er bald auf: es lässt sich nur sehr unkomfortabel in dem Fensterquintett bestehend aus dem Hauptfenster mit seinen zahllosen Menüpunkten und seiner Komponentenpalette, dem Quelltexteditor, dem Objektinspektor, der Objekt-Hierarchie und dem Startformularfenster ohne Hilfe der Maus navigieren.

Über einen weiteren Punkt lässt sich gewiss streiten: Die Unterteilung des Programmcodes einer Unit in den so genannten Interface- und Implementation-Bereich mag gewiss vorteilhaft in dem Sinne sein, dass ein fremder Benutzer der Klasse bereits mittels eines kurzen Blickes auf den Interface-Bereich erkennt, wie er diese Klasse verwenden kann. Andererseits hat diese Redundanz bei meinen Schülern immer wieder zu Fehlermeldungen geführt, weil sie z.B. versehentlich eine Methode nicht im Interface angegeben oder sie den Methodennamen nachträglich im Implementation-Bereich verändert haben. Ganz häufig wurde im Implementation-Bereich vergessen, jedem Methodennamen den Klassennamen (gefolgt von einem Punkt) voranzustellen. Es wäre wünschenswert, wenn Delphi lediglich eine Klassendeklaration pro Unit erlauben würde, damit die Schüler zumindest von dieser Eigenheit befreit würden. Wenn man darüber hinaus bedenkt, dass die Schülerprogramme in der Regel doch recht überschaubar bleiben, könnte man die Notwendigkeit des Interface-Bereichs überhaupt in Frage stellen. Wie oft wurde ich nicht schon gefragt, an welcher Stelle im Quelltext Variablen und Konstanten deklariert werden können oder an welcher Stelle andere Klassen mittels 'uses' eingebunden werden können.

Vergleiche ich abschließend die Fehlermeldungen von Delphi mit denen, die ich vor etwa zehn Jahren mit Turbo-Pascal in meinem eigenen Informatikkurs als Schüler beobachtet habe, so komme ich zu dem Ergebnis, dass die Fehler, die wir Schüler damals gemacht haben (z.B. ein Semikolon vor einem 'else' oder die Verwendung einer nicht deklarierten Variable) heute bei Delphi um eine große Anzahl von neuen Fehlern ergänzt werden, die wir damals gar nicht machen konnten, weil es sie ganz einfach nicht gab.

Die hier veröffentlichten Inhalte stellen keine Meinungsäußerungen der Studienseminare Hamm Arnsberg dar.
© Redaktion If Fase