Objektorientierte Sprachen: OOPs up
Lange mußten wir warten, jetzt ist er da: »M:OOP«, der erste Compiler einer objektorientierten Sprache. Doch nicht das weit verbreitete »C++« hat den Zuschlag bekommen: »M:OOP« ist ein »Objective C«-Compiler.
Lange herrschte Funkstille um die Programmiersprachen auf dem ST. Da gab es diverse C-Entwicklungsumgebungen, mehr oder weniger schlechte Basic-Umsetzungen, einige spärlich gesäte Pascal-Adaptionen und einige Modula-2-Programmpakete — darüber hinaus eine Palette von Assemblern: Ende der Fahnenstange!
All diesen Programmiersprachen ist das konventionelle Modell der Programmierung gemein: Die Programme enthalten auf der einen Seite Daten, auf der anderen Seite Funktionen, die diese Daten verändern.
Dieses Modell der klassischen Programmierung wird seit neuestem vor allem auf den Workstations und PCs von einer neuen Programmierphilosophie verdrängt: Die objektorientierte Programmierung (OOP) hält Einzug in die Entwicklungsabteilungen der Software-Firmen.
Dies hat handfeste Gründe, die aus der Grundidee der OOP resultieren: Die OOP faßt Daten und Funktionen (»Methoden«) zu einem einzigen untrennbaren Gebilde, dem Objekt, zusammen. Aus dieser Idee resultiert, daß die Daten des Objekts nicht von außen, sondern nur vom Objekt selbst verändert werden sollen, denn sie sind ja fester Bestandteil desselben. Dazu schickt ein Objekt einem anderen eine entsprechende Nachricht, auf die dieses dann reagiert. Während es »C + + « noch gestattet, bestimmte Variablen als »public« zu deklarieren und somit von jedem Objekt verändern zu lassen, verbietet dies »Objective-C«, dessen Umsetzung »M:OOP« das Berliner Software-Haus »Fries & Partner« auch für den ST anbietet.
Diese »Verkapselung« der Objekte hat einen Vorteil: die ideale Realisierbarkeit parallel ablaufendender Prozesse, wie sie heute von nahezu allen Betriebssystemen erwartet wird. Da jedes Objekt in sich als autark gilt und nicht unbedingt an eine bestimmte Reihenfolge des Programmablaufs gebunden ist, kann ein Objekt gleich mehreren anderen Nachrichten senden, auf die sie dann parallel reagieren können. Ideale Voraussetzungen — nicht nur für Multitasking-Betriebssysteme, sondern auch für Mehrprozessorcomputer. Die Verkapselung jedes einzelnen Objekts bedingt allerdings noch weitere Vorteile: Sämtliche Variablen, die das Objekt benutzt, sind nur in ihm selbst deklariert und dürfen auch nur vom Objekt selbst genutzt werden. Diese Programmierstrategie versucht schon C zu realisieren, allerdings mit mäßigem Erfolg: Lokale Variablen von C verlieren nach dem Verlassen der Funktion, in der sie deklariert sind, sofort ihren Wert. Abhilfe schafft nur eine »static«-Deklaration, die jedoch den Nachteil mit sich bringt, daß das C-Programm mehr und mehr statische Variablen benutzt, deren Bedeutung immer unverständlicher werden. Große Programmprojekte, die von mehreren Programmierern durchgeführt werden, führen dann zu einer Unzahl globaler Variablen, und die Wahrscheinlichkeit doppelt benannter Variablen oder Funktionen steigt. In der OOP ist es kein Problem, selbst Methodennamen doppelt zu vergeben, und Variablen existierten ja ohnehin nur innerhalb des Objekts. Ergo können mehrere Methoden gleichen Namens auf verschiedene Objekte bezogen auch völlig verschiedene Bedeutungen haben. So muß der Programmierer bei der Definition von Objekten keine Rücksicht auf etwaige Namensähnlichkeiten nehmen.
Eine wirkliche Spezialität der OOP ist die Vererbung. Der Programmierer definiert dabei ein neues Objekt, indem er schlicht weg die Unterschiede zu bereits bestehenden Objekten beschreibt. Dies setzt natürlich eine ausreichend umfassende Bibliothek von Objekten (auch »dass« genannt) voraus. Die Vererbung spart dem Programmierer einen enormen Aufwand.
So muß er nicht zwei sehr ähnliche und doch eigenständige Funktionen entwickeln, sondern definiert ein einziges Objekt und seine natürlichen Unterschiede zum zweiten. Dadurch ist eine wirklich effektive Nutzung der Bibliotheken gewährleistet. Während der Programmierer in C sehr umfangreiche Bibliotheken benötigt, die mitunter sehr ähnliche Funktionen enthalten (Beispiel: »strcmpO« und »memcmpO«), wäre in Objective-C nur ein einziges Objekt vonnöten, aus dem sich das zweite konstruieren läßt.
Bei seiner Arbeit legt der Compiler dementsprechend auch nur ein einziges Objekt an, welches dann beide Informationen umfaßt. Ein herkömmlicher C-Compiler hätte zwei eigenständige Funktionen speichern müssen.
Methoden suchen
Nicht zuletzt realisiert Objective-C das »Dynamic Binding«, das Linken zur Laufzeit. Herkömmliche Linker verbinden die benötigten Funktionen einer Bibliothek sofort nach der Kompilation zu einem Gesamtprogramm. Objective-C hingegen erlaubt es Programmen, auch Methoden anzusprechen, die dem angesprochenen Objekt unbekannt sind. Es sendet daraufhin die empfangene Nachricht an die ihm übergeordnete »dass« weiter. Dies setzt sich bis zur obersten aller »classes« fort. Sofern kein Objekt etwas mit der angesprochenen Methode anfangen kann, tritt ein Laufzeitfehler auf, der sich vom Programm entsprechend verarbeiten läßt, beispielsweise dadurch, daß es Methoden nachlädt. Somit sind unter Umständen komplexere Fehler leichter zu finden, und mit dem Speicher wird sparsamer umgegangen: Es ist kein Problem mehr, ein 4-MByte-Programm auf einem Rechner mit nur 640 KByte Speicher zu verwenden: Nicht benötigte Programmteile liegen auf der Festplatte, und nur der gerade aktive Teil des Programms belegt Speicher. Außerdem braucht der Compiler bei einer Programmänderung nicht mehr das gesamte Programm neu übersetzen, unveränderte ausgelagerte Programmteile benötigen keinen Compiler-Durchlauf.
Mit M:OOP liegt nun der erste Objective-C-Compiler für den ST vor. Genauer gesagt: der erste Objective-C-Precompiler, denn der Compiler erzeugt mitnichten linkfähige Objektdateien, sondern reinen C-Code. Das schränkt den Anwenderkreis schnell ein: Ohne einen lauffähigen C-Compiler können Sie mit M:OOP gar nichts anfangen. Und auch wenn Sie einen C-Compiler besitzen, öffnet Ihnen dies nicht unbedingt die Pforte zur objektorientierten Programmierung. Einzig und allein Besitzer von »Mark-Williams-C« oder »Turbo-C« dürfen sich über funktionsfähige M:OOP-Libraries freuen. Für andere C-Compiler komplettiert der Hersteller diese Libraries derzeit.
Dafür ist der Preis des M:OOP-Entwicklungspakets erfreulich niedrig: Für nur 198 Mark kauft man nur das, was er wirklich braucht, nämlich den Compiler ohne Schnörkel.
M:OOP ist keine Demonstration von Bedienungskomfort. Eine Kommandozeilenversion des Compilers gestattet den Aufruf aus Command-Line-Interpretern (CLIs) heraus, Batch-Dateien automatisieren hierbei den Programmablauf. Darüber hinaus liefern Fries & Partner ein Compiler Accessory, das sich jedoch prinzipbedingt als Speicherfresser entpuppt. Sowohl Accessory als auch Kommandozeilenversion benötigen einige Dateien zum reibungslosen Ablauf der Kompilation. Die dazu notwendigen Pfade muß der Anwender beim Kommandozeilenprogramm als eigene Environment-Variable eintragen, das Accessory hingegen kümmert sich keinen Deut darum, so daß unter Umständen längeres Suchen fällig ist. Allzuviel bleibt an M:OOP aber ohnehin nicht zu bedienen, ganze drei Schalter zieren das Hauptmenü. Da M:OOP weder über einen eigenen Editor noch über einen Linker oder ähnliches verfügt, erübrigen sich weitere Einstellungen (Abb. 1).
Der Compiler erweist sich als zügig und zuverlässig. Fehler konnten wir in der Testzeit nicht feststellen; das war aber auch nicht anders zu erwarten, zumal Compiler-Fehler in der Regel erst beim täglichen harten Einsatz aufzuspüren sind.
Die Implementation des von Cox [1] beschriebenen Objective-C realisierten die Entwickler mit sehr wenigen Einschränkungen. Die ärgerlichste ist, daß die Gesamtlänge der an eine Methode übergebenen Variablen 16 Byte nicht überschreiten dürfen.
Die Geschwindigkeit von M:OOP mit der eines C-Com-pilers zu vergleichen, wie es in anderen Computerzeitungen geschehen ist, halten wir für ziemlich unsinnig, zumal ein C-Compiler ein reines Assembler-Programm, M:OOP aber »nur« C-Sourcecode erzeugt.
Da Objective-C ganz im Gegensatz zu C++ in der PC-Weit noch nicht allzu weit verbreitet ist, sollte die Frage der Portabilität auch bei einem Precompiler gestellt werden. Erfreulicherweise steht M:OOP für eine Reihe von Betriebssystemen zur Verfügung, so daß Sie M:OOP-Programme bei Bedarf auch leicht von einem Rechnersystem zum anderen portieren können.
Gute Literatur ist gefragt
Der Hersteller liefert M:OOP mit einem 85seitigen deutschsprachigen Handbuch aus, das dem Neuling in der OOP allerdings nur wenig weiterhilft. Das ist nur als Konsequent zu bezeichnen, zumal M:OOP Objective-C-kompatibel ist und zum Erlernen dieser Programmiersprache diverse hervorragende Lehrbücher erhältlich sind. Einzig die mitgelieferten classes (Sammlungen von Objekten, ähnlich den C-Libraries) könnten etwas umfangreicher sein. Da der Produzent anscheinend die Entwicklung der classes nicht selbst übernehmen will, bietet er seinen Kunden einen Tauschservice an, durch den die M:OOP-Anwender untereinander ihre Errungenschaften austauschen können. Ähnlich, wie für »Signum« eine ansehnliche Sammlung exotischer Schriften zusammengekommen ist, sollen nun die Anwender auch die spärliche M:OOP-Bibliothek ausbauen. (uw)
Wertung
Name: M:OOP Version 2.0
Vertrieb: Fries & Partner
Preis: 198 Mark
Stärken: □ fast vollständige Implementation von Objektive-C □ auch für andere Computersysteme erhältlich, dadurch hoh-ge Portabilität □ kompatibel zu Objektive-C □ Tauschservice des Herstellers für Classes
Schwächen: □ Libraries nur für Turbo-C und Mark-Williams-C □ übergebene Variablen dürfen nur 16 Byte groß sein □ knappes Handbuch □ kleine Classes-Bibliothek
Fazit: hochwertige Objektive-C-Implementation für den Atari ST
Fries & Partner, Eislebener Straße 7, 1000 Berlin 30
Literaturverweise:
[1] B. J. Cox, Object Orientated Programming, Addison-Wesley 1987
Laurenz Prüßner