Objektorientierung - es gibt NUR Objekte

Ein System, das vorgibt, in objektorientierte Programmierung einzuführen, muß selbst objektorientiert aufgebaut sein. Diese Forderung ist eingehalten. Alles, was in der Delphi-Karel-Welt ist, sind Objekte und als solche ansprechbar. Deshalb wurde auch z. B. die Spur, die der Roboter ziehen kann, als Objekt angelegt und kann wie jedes Objekt auch wieder entfernt werden. Ebenso werden in den Container des Robots die aufgesammelten Objekte getan und können nach dem LIFO-Prinzip (stack) wieder heraus genommen werden.

Architektur / Design

Die Klassenhierarchie ist klassisch angelegt mit relativ tief gestaffelten Vererbungsketten. Wo die Situationen es erfordern, sind polymorphe Zugriffe vorhanden (Darstellung, Container).

Die Struktur der Klassen in Karel D. Robot ergibt sich aus der Sachlogik des Anwendungsproblems, nämlich dem Modell einer Welt mit Sachen und Lebewesen, wie im OOA-Modell dargestellt. Üblicherweise werden die so gefundenen Klassen dann ‚Fachklassen’ genannt, womit implizit unterstellt wird, daß sie kein Wissen über die Art und Weise ihrer Darstellung auf dem Bildschirm (View) haben und nicht an der Steuerung (Controller) durch die Entgegennahme von Events beteiligt sind.

Das Konzept der Trennung dieser drei Zuständigkeiten wird Model-View-Controller Pattern genannt und ist in Verbindung mit dem 4-Schichten-Modell das derzeit übliche Verfahren, um große Softwaresysteme zu strukturieren und entwerfen. DELPHI-Karel folgt diesem Prinzip teilweise nicht.
Die Idee war, verhaltensvollständige Objekte zu entwerfen, die selbst in der Lage sein sollten, sich dem Benutzer auf dem Bildschirm zu präsentieren. Das ist die alte Smalltalk-Idee, die meines Erachtens bei Anwendungen mit grafischen Objekten immer noch ihre Berechtigung hat und dabei durchaus Vorteile bietet. Insofern ist der Begriff der Fachklassen hier erweitert, als daß jedes Objekt per definitionem (TItem.Zeigen) seinen spezifischen View mitbringt (und daher auf das GUI zugreifen kann) und manipulierbar ist.

Die grafische Grundlage für DELPHI-Karel ist uGrafik, eine Sammlung von Klassen, die eben diesem Prinzip folgen. Daher ist die Implementation des Gesamtsystems vergleichsweise einfach und elegant zu lösen.
 

Zweiseitige Assoziationen

Wenn Objekte wie hier sich selbst darstellen sollen, muß ein Zugriff auf Systemkomponenten (Canvas usw.) organisiert werden, was in Fachklassen eigentlich nichts zu suchen hat. Das wird hier mit Hilfe der Grafik-Bibliothek uGrafik realisiert.

Die Welt registriert als übergeordnete Instanz die Anwesenheit aller Objekte, gleichzeitig benötigen die Objekte Informationen von der Welt. Da Delphi keine Zirkelbezüge in der Schnittstelle zuläßt, werden die erforderlichen Assoziationen im Implementation-Teil aufgebaut. In den Schnittstellen werden nur die Klassen importiert, die auch exportiert werden müssen.

Mehrere Roboter / Critters

Selbstverständlich können sich mehrere Exemplare 'gleichzeitig' in der Welt bewegen. In dieser Version ist jedoch keine echte Nebenläufigkeit eingebaut. Das hat zur Folge, daß ein Objekt seine Bewegung abgeschlossen haben muß, bevor das nächste startet. Da ein Weg 30 pix beträgt, ist das natürlich deutlich sichtbar. Ein Effekt, mit dem man aber das Problem der Nebenläufigkeit schön sichtbar machen kann.

Bildschirmauflösung - Darstellung

Unter Windows 2000 kommt es manchmal vor, daß die Zeichen 1..12 , A..N (Zeilen/Spalten) in einem zu kleinen Font dargestellt werden. --> F.A.Q

Version-Historie
 

2.4.1	25-AUG-05	Das Gesamtpaket in einen Installer eingebunden.
2.4	17-APR-05	Neu : TLagerhaus eingeführt, TKarel.Einlagern, TKarel.Auslagern. Neu : TBlackhole als 'Schwarzes Loch' oder als rückstandsfreier Müllschlucker verschlingt jedes Objekt. TStack.SollLaenge erlaubt jetzt unterschiedliche definierte Listenlaengen.  Bug in TRobot.Zeigen beseitigt, Setpos war nicht virtual.
2.3.3.	14-MAR-05	TRichtung = (Nord,Ost,Sued,West). Das Zeichen A als Aufzählungstyp oder Char irritierte im Anfangsunterricht.
2.3.2	14-FEB-05	Welt.SetLinienFarbe, TKarel.VorDemAbgrund, redaktionelle Änderungen
2.3.1	07-JAN-05	Schönheitsfehler beseitigt. Demo.exe hinzugefügt.
2.3	02-JAN-05	Tutorial   --> Menü-?
2.2.1	30-Nov-04	TRobot kann Spur machen. Bugs in TItem beseitigt; Bild wurde nicht gelöscht.
2.2	25-JUL-04	Einfacher TeachIn-Mode mit Copy/Paste aus dem Protokoll Interne Sicherheitsstandards erhöht
2.1.3	20-JUL-04	Robot speichert das Gedächtnis nicht selbst; sondern Laden und Speichern erfolgt direkt aus der Listbox   --> Menü-Datei Aktualisierung der Anzeige in der Listbox erfolgt durch aktiven Aufruf durch den Roboter. Geschwindigkeit verbessert.
2.1	24-JUN-04	Robots haben ein Gedächtnis (TMemory, TShadow), wo sie sich die Actions und Felder merken, die sie seit dem Start besucht hatten (DaGewesen). Die Informationen werden als Protokoll geführt --> Menü-Datei.
2.0.7	14-JUN-04	Geschwindigkeit in TCritter, TRobot
2.0.6	26-APR-04 08-MAY-04	Kleine textuelle Änderungen Für Delphi 4 angepaßt (Christian Steinbrucker).
2.0.5	18-APR-04	THaufen in TMuell umbenannt, bug in VorneFrei beseitigt
2.0.4	15-APR-04	TLabyrinth
2.0.3	11-APR-04	Roboter kann Aufnehmen, ablegen Fußspuren - TSpur
2.0.2	05-APR-04	Programm merkt sich bei Recompilieren die gewählt Welt. Automatisches Erzeugen des Roboters entfernt. Jetzt in uControl.pas.
2.0.1	02-APR-04	User-ControlForm ausgelagert. Der Benutzer sieht nur eigene Komponenten in ControlFrm
1.3	28-MAR-04	TWelt abstrakt; Unterklassen
1.2	27-MAR-04	Clean City, My World
1.1.3	26-MAR-04	Welten erzeugen in TWelt
1.1.2.	24-MAR-04	Trainingscamp
1.0	22-MAR-04	Docs, Robot: VorneFrei, HindernisPruefen, Rechtsdrehen statt Links
0.9.3	18-MAR-04	Bilder für Items
0.9	03-MAR-04	'Kap der guten Hoffnung' - TItem