|
|
|
Bisher erschöpft sich die Unterstützung der Lehrerinnen und damit der Schülerinnen für die Vorbereitung zum Zentralabitur im Wesentlichen in dem Angebot einiger weniger grundlegender Vorgaben, Beispielaufgaben und Schnittstellen. Der Blick in die veröffentlichten Beispielaufgaben ließ im vergangenen Jahr erhebliche Fehler deutlich werden. Diese wurden offensichtlich, als ich Lösungen für die Aufgaben in Python implementieren wollte: www.die.informatik.uni-siegen.de/pipermail/gi-fg-informatische-bildung-nrw/2005-August/000090.html Die Lösungen wurden unter ddi.uni-wuppertal.de/humbert.in.hagen.de/ddi/ (unten auf der Seite) veröffentlicht.
Klassendiagramm TList nach der Vorlage »datentypen-objekto-ansatz«
Auch im Jahr 2006 (ein Jahr nach meiner dezidierten Kritik) wird
weiterhin als Beispiel von offizieller Seite
www.learn-line.nrw.de/angebote/abitur-gost/download/if-datentypen-objekto-ansatz-delphi.pdf
die Klasse TList (Seite 9–11) angegeben. Wer
erinnert sich noch, woher das »T« kommt? Es wurde vor langer Zeit für
Implementierungen in Pascal eingeführt, um selbstdeklarierte Typen(!) zu
bezeichnen – müsste jetzt nicht »K« für Klasse gewählt werden
–?
Da z.B. Standarddatentypen nicht über ein Präfix verfügen, sollten sich
die Autoren m.E. von dieser überholten und didaktisch umstrittenen
Präfixnotation verabschieden. Eher sollte über eine vereinbarte
Schreibweise (Gross für Klassen - klein für Objekte) sichergestellt
werden, was eine Klasse ist, denn über ggf. mehrdeutig interpretierbare
Präfixe.
Es wird eine Klasse angegeben, die mit vierzehn
Methoden ausgestattet ist. Übliche, d.h. in der Informatik
bekannte Schnittstellen zur Listenverwaltung enthalten (je nach
Implementierung) ca. sechs Methoden, um den notwendigen
Funktionsumfang zur Verfügung zu stellen. Ich fragte die Autoren
öffentlich, wie sie auf diese Schnittstelle gestossen sind. Ich erhielt
auf meine Anfrage
www.die.informatik.uni-siegen.de/pipermail/gi-fg-informatische-bildung-nrw/2005-August/000090.html
keine Antwort. Sobald Klassen deklariert werden, sollte dafür Sorge
getragen werden, dass sie minimal festgelegt sind. Es
ist jeder informatischen Strukturierung abträglich, wenn (wie in diesem
Fall) mehrere Methoden zur Erledigung einer Aufgabe verwendet werden
können. So etwas sollte nicht veröffentlicht werden (selbst wenn es
Bestandteil einer Klassenbibliothek ist).
Erst recht kann eine solche Schnittstelle nicht zum Vorbild erklärt
werden. Jedes von mir konsultierte Standardwerk der Informatik zeigt auf,
wie die Datenstruktur Liste implementiert werden kann, ohne einen
derartigen Wildwuchs an Methoden bereitzustellen.
Ich schlage vor, statt dieser Schnittstelle zum Beispiel die folgende Schnittstelle zu verwenden.
Eine [relativ] minimale Klasse zur Nutzung von Listen
Sie findet sich in der Standardliteratur an Stellen, die sich mit der
effizienten Implementierung von Listenstrukturen beschäftigen. Darüber
hinaus wird üblicherweise in der deutschsprachigen Informatikliteratur
mit deutschen Bezeichnern gearbeitet, wenn Datenstrukturen beschrieben
werden. Als Beispiel sei auf die Standardeinführung in die Informatik von
Helmut Balzert verwiesen. Im einführenden »Lehrbuch Grundlagen der
Informatik« wird in Kapitel 17 ausführlich zu Listen gearbeitet.
Auch Balzert scheut sich nicht, auf andere einführende Werke zu verweisen
und gerade bei der Listendarstellung differenziert auf die Seiteneffekte
einer an der effizienten Implementierung orientierten Datenstruktur
hinzuweisen.
Eine minimale Klasse zur Nutzung von Listen vgl. Balzert
Maßgabe jeder informatischen Modellierung muss eine möglichst klare und verständliche Schnittstelle sein. Gerade für häufig benutzte Schnittstellen werden darüber hinaus gewisse Anforderungen an die Effizienz und Eleganz der Implementierung gestellt.
In dem o.g. Dokument wird durchgängig ein Begriff benutzt, der fachlich falsch ist: »Benutzerschnittstelle« (ab Seite 30ff). Vor ca. 20 Jahren wurde in der Informatik erkannt, dass dieser Begriff durch Benutzungsschnittstelle zu ersetzen ist. Es ist sehr ärgerlich, wenn solche Fehlleistungen öffentlich publiziert werden.
Wenn Sie sich bis zu dieser Frage vorgearbeitet haben und diesen
Artikel nicht als beleidigend empfinden, werden Sie sich gewiss die in
der Zwischenüberschrift gestellte Frage gestellt haben. Das zentrale
Problem besteht darin, dass Pascal eine stark typisierte Sprache ist und
nicht erlaubt, dass im Nachhinein Daten eines anderen Typs verwendet
werden, als bei der Deklaration festgelegt. Daraus resultiert, dass alle
Elemente, die in einem Graphen, einer Liste, etc. organisert werden,
letztlich von einer vorher festgelegten Klassen abzuleiten sind. Da die
Mehrfachvererbung nicht erlaubt ist, schränkt diese Festlegung aller
streng typisierten Sprachen die Möglichkeiten, beliebige Objekte in einer
solchen Datenstruktur zu organisieren, ganz erheblich ein.
Hier bieten schwach typisierte Sprachen einen grossen Vorteil, da sich
jederzeit beliebige Strukturen miteinander verzahnen lassen. Dennoch kann
an kritischen Stellen über eine Typprüfung erreicht werden, dass die
Typsicherheit (wenn sie gefordert ist) gewährleistet werden kann.
Die nächste Frage betrifft die Möglichkeit, vordefinierte Typen zu erweitern. Dies ist in streng typisierten Sprache üblicherweise nicht vorgesehen. Dabei wird deutlich, dass Mischsprachen, die imperativen Ursprungs sind, für die objektorientierte Implementierung aus didaktischer Sicht nicht gut geeignet sind, da sie mit Restriktionen aufwarten, die aus objektorientierter Sicht mit nicht orthogonalen Einschränkungen verbunden sind. Das Orthogonalitätskriterium ist für die didaktische Bewertung der Eignung einer Sprache ein hartes Kriterium und sollte nicht ohne schwerwiegende Gründe mißachtet werden.