Grundlagen der Informatik I “Programmierung”

Es sei an dieser Stelle angemerkt, daß die genaue Typisierung mancher Argumente nach einer Datenstruktur
verlangt, die üblicherweise nicht zu den vordefinierten Typen der Eiffel-Basisbibliothek gehört. Zur Speicherung
der Bücher und Entleiher einer Bibliothek sowie der Autoren des Informationssystems benötigen wir eine
generische Klasse, die dem mathematischen Konzept der Menge entspricht. Dies ist nötig, weil wir beliebig
viele Bücher, Entleiher und Autoren zulassen wollen, Elemente hinzufügen, nach Kriterien wie Autor und
Titel (und ggf. Entleihstatus) suchen, und entnehmen wollen. Indizes, wie Felder sie anbieten, werden nicht
gebraucht. Stattdessen muß gesichert sein, daß Elemente nicht doppelt vorkommen. Aus diesem Grunde muß
zu den obengenannten problemspezifischen Klassen eine generische Klasse SET hinzugefügt werden, deren
Dienstleistungen sich aus den Anforderungen des Problems und den üblichen Mengenoperationen ergeben.
4.1.6.3 Vollständige Klassenstruktur
An dieser Stelle müsste nun die obige Beschreibung in eine vollständig beschriebene Struktur von Eiffel-Klassen
umgesetzt werden, in der alle Dienstleistungen, die für die Modellierung des Problems relevanten Attribute
(z.B. die Komponenten eines Buches) und eventuell weitere für die Verarbeitung hilfreiche features explizit
genannt, typisiert und mit Vor- und Nachbedingungen versehen sind. Der selektive Export gemäß der oben
genannten Kunden wäre explizit zu vereinbaren und Erbbeziehungen wären in inherit-Klauseln zu formulieren.
Es würde den Rahmen dieses Skriptes sprengen, dieses Beispiel bis ins letzte Detail auszuführen. Wir belassen
es daher bei der bisher gegebenen Feinspezifikation, die mit entsprechendem Platz- und Zeitaufwand (aber
ohne weitere Entwurfsüberlegungen) in eine vollständige Klassenstruktur umgesetzt werden kann.
4.1.7 Ästhetik der Programmierung
Ein letzter Aspekt, der beim Entwurf – genauso wie bei der Implementierung – eine Rolle spielen sollte, ist
eher ästhetischer Natur. Es gibt viele Programme, die ihre Aufgabe erfüllen, aber unter diesen gibt es welche,
deren Vorgehensweise man als “schlechten Programmierstil” bezeichnen würde.
Was ein guter und was ein schlechter Programmierstil ist, läßt sich nicht in voller Allgemeinheit sagen, da
die Ansichten darüber zum Teil auseinanderdriften. Manche halten Programme für gut, wenn sie nur wenige
Klassen und Routinen benötigen, kurzen Code haben, oder durch geschickte Anordnung von Anweisungen
sehr effizient sind. Andere bevorzugen Programme, in denen der Code einer einzelnen Routine kurz ist.
Nach unserer Ansicht sollte ein Entwurf so gestaltet sein, daß seine Struktur für Andere durchschaubar
bleibt und die wesentlichen Ideen ohne große Erklärungen erkennbar sind. Dies ist meist der Fall, wenn ein
klarer Bezug zur realen Welt zu erkennen bleibt, die modelliert wird, wobei auch die Namensgebung für
Klassen, features und Parameter eine nicht unwesentliche Rolle spielt. Auch bedeutet dies, daß Zusicherungen
– die ja auch einen Teil der Dokumentation eines Programms darstellen – nur features benutzen, die auch
exportiert werden. 8 Interessanterweise stimmen die Beurteilungen konkreter vorgegebener Programme durch
verschiedene Personen meist überein 9 und deshalb ist es auch hier wichtig, Erfahrungen zu sammeln und
eigene Programme der Kritik anderer zu stellen, um die eigene Beurteilungsfähigkeit zu schärfen und im
Laufe der Zeit “bessere” Programme zu schreiben.
Ästhetik ist ein Kriterium, das zuweilen auf Kosten der Effizienz geht, aber bedeutend ist für das Verständnis.
Dies geht Hand in Hand damit, daß man die Korrektheit eines Programms leicht einsehen und ggf. auch leicht
beweisen kann. Oft versteht man ein Programm viel besser, wenn man die Gründe aufgeschrieben hat, warum
der Entwurf und die implementierte Methode auch tatsächlich funktioniert. Dies leitet uns über zum nächsten
Thema, der Implementierung von Programmen und dem Nachweis ihrer Korrektheit.
8 Dies wird von Eiffel nicht kontrolliert und leider sind auch die Musterlösungen zuweilen von diesem Prinzip abgewichen.
9 Sie sollten während einer Übungstunde einmal Kriterien zusammentragen, ausdiskutieren und dann eine Liste der Kriterien
für einen guten Programmierstil, zusammenstellen, auf die Sie sich einigen können.