"Von Stiften und Mäusen" oder Was heißt
objektorientierte Modellierung?
- Eine kritische Betrachtung -
von
Siegfried Spolwig
Stifte und Mäuse wurde als Konzept zur
Einführung in die objektorientierte Programmierung entwickelt.
Strukturelle Restriktionen und die Art des Einsatzes lassen erhebliche
Zweifel aufkommen, ob es noch für einen zeitgemäßen
Einführungsunterricht brauchbar ist. |
1. Einleitung
Das Unterrichtskonzept "Von Stiften und Mäusen" (SuM)
[vgl.1] erschien
vor ca. 10 Jahren. Die Autoren haben sich ein
großes Verdienst um die Einführung der Objektorientierung in den
Informatikunterricht erworben und es gebührt Ihnen die Ehre, unter den
ersten gewesen zu sein, die ein schülergerechtes objektorientiertes
Unterrichtskonzept entwickelt haben, das sich bis heute einer
erstaunlichen Lebendigkeit und zunehmender Verbreitung erfreut. Es wird
inzwischen in Rahmenlehrplänen genannt, von Bildungsservern empfohlen, in
vielen Schulen und Lehrerfortbildungen eingesetzt.
Mittlerweile ist SuM nahezu in alle schulrelevanten Sprache portiert,
zuletzt nach Delphi und Python. Es muss also gut sein, obwohl der Ansatz
schon ein wenig angejahrt erscheint und es heute eine Reihe von didaktisch
reduzierten Tools (z. B. BlueJ, Fujaba & Mr. Dobs, UMLed/Delphi) gibt,
die dem Stand der Technik entsprechen.
Erstaunlicherweise findet man praktisch nirgends ein Wort der Kritik.
Das zumindest erscheint verdächtig. Es stellt sich die Frage, ob SuM immer
noch geeignet ist, die Ziele eines zeitgemäßen Informatikunterrichts, der
Modellierung und geeignete Modellierungstechniken in den Mittelpunkt
stellt, zu erreichen.
SuM war zunächst für den Anfangsunterricht entwickelt worden; fleißige Programmierer haben inzwischen Programme und Klassen
vorgestellt, die dieses Niveau weit hinter sich lassen und damit den
Anspruch demonstrieren, mit SuM könne man viel mehr machen. Hier wird soll der 'SuM-Kern' und seine Eignung für
den Einführungsunterricht in die objektorientierten Programmierung
untersucht werden.
2. Das informatische Konzept
Der Kern von SuM ist eine sprachenunabhängige Klassenbibliothek
(Bildschirm, Maus, Tastatur, Stift, Anwendung), die einen PC beschreibt
[2]. Die Dokumentation verbirgt die Attribute der Objekte und stellt sich
wie ein abstrakter Datentyp dar, der nur Funktionen anbietet. Die Klassen
sind erweiterbar. Mit diesem Angebot lassen sich nur Aufgaben bestimmter
Problemklassen lösen (Persistenz z. B. ist nicht vorgesehen). Des Weiteren ist impliziert, dass sich die erzeugten Objekte selbst auf dem
Bildschirm darstellen (i. d. R. mit einem Attribut Stift gezeichnet
werden).
Diese Entwurfsentscheidung hat zur Folge, dass neuere Konzepte, die die
Trennung von Daten und ihrer Repräsentation vorsehen (z. B. MVC), nicht
möglich sind.
Modellierung ist seit einiger Zeit das neue Zauberwort der
Informatik-Didaktik. Professorale Arbeiten und kluge Dissertationen haben
es eben auch nicht eben leichter und klarer für den amtierenden Lehrer
gemacht. Die objektorientierte Programmierung ist angetreten mit dem Anspruch
und Versprechen, Objekte und Ausschnitte der Realwelt so abzubilden wie
sie sind. Jedes Analyseobjekt hat seine Entsprechung in der natürlichen
realen Welt und übernimmt dessen Identität im Modell. Meyer, einer der
Väter der Objektorientierung hat es so formuliert:
"Deshalb verbringen objektorientierte Entwerfer normalerweise ihre
Zeit nicht mit akademischen Diskussionen darüber, wie Objekte zu finden
sind: In der physikalischen und abstrakten Wirklichkeit sind die Objekte
modelliert und warten nur darauf, aufgelesen zu werden."
[3]
Diesem Anspruch genügt SuM in der jetzt vorliegenden Entwicklung und
einer verbreiteten Praxis nicht.
3. Didaktische Analyse
Das Konzept folgt zunächst
richtigen Überlegungen.
"Die Bereitstellung einer sehr kleinen, aber dennoch schon recht
leistungsfähigen Bibliothek fertiger Klassen, ist ein wesentliches
Prinzip des hier vorgestellten didaktischen Konzepts. Und auch deren
Überschaubarkeit ist für den Anfangsunterricht äußerst wichtig.
Einerseits wird dadurch die Verwendung fertiger Bausteine auf der
Grundlage einer Dokumentation geübt, andererseits wird frühzeitig die
eigene Erweiterung einer bestehenden Klassenbibliothek angeregt."
[4]
3.1 SuM als Turtle
Die Unterrichtssequenz SuM beginnt mit dem übenden Gebrauch von
gegebenen Objekten. Ein typisches erstes Programm (Klasse) zeigt ein "Haus
vom Nikolaus" [5] :
public class Nikolaus1
/* verwendete Objekte */
private Bildschirm meinBildschirm;
private Stift meinStift;
public void fuehreAus()
{
/* Aufbau der Objekte */
meinBildschirm=new Bildschirm();
meinStift=new Stift();
/* Nachrichtenteil */
meinStift.bewegeBis(100,100);
meinStift.runter();
meinStift.bewegeBis(140,100);
meinStift.bewegeBis(100,60);
meinStift.dreheBis(60);
meinStift.bewegeUm(40);
meinStift.dreheUm(-120);
meinStift.bewegeUm(40);
meinStift.bewegeBis(100,60);
meinStift.bewegeBis(100,100);
meinStift.bewegeBis(140,60);
meinStift.bewegeBis(140,100);
/* Abbau der Objekte */
meinStift.gibFrei();
//meinBildschirm.gibFrei();
}
}
Bereits hier sieht man, dass es sich nicht um die Abbildung eines
Objekts ‚Haus’ handelt, sondern um eine Strichzeichnung, die der Stift auf
den Bildschirm schreibt, quasi ein anweisungsgesteuertes Malprogramm. Es
werden zwar die Objekte Bildschirm und Stift benutzt, jedoch hat das
Produkt abgesehen von der OO-Notation mit Objektorientierung noch nicht viel zu tun. Das ging mit LOGO
und Turtle im Prinzip genauso. Diese und ähnliche Beispiele können gut zum
Lernen von Sequenzen und Kontrollstrukturen dienen.
Ein weiterer positiver Aspekt ist die Visualisierung der Ergebnisse, die
dem Schüler die unmittelbare Überprüfbarkeit seiner Arbeit gewährleistet.
3.2 Entwicklung und Erweiterung eigener Klassen
Das Konzept sieht aus nahe liegenden Gründen Entwicklung und
Erweiterung eigener Klassen vor:
"Die zwar griffige Bezeichnung »Stifte und Mäuse« für die hier
vorgestellte Konzeption wird bei oberflächlicher Betrachtung häufig
missverstanden. So gibt es immer wieder Betrachter, die glauben mit
diesem Konzept gehe die Reduktion auf eine Verwendung der vier
Basisklassen einher.
Das ist falsch!
Vielmehr gehört die Erweiterung zu einer kurseigenen Klassenbibliothek
wesentlich zum didaktischen Konzept." [4].
Leider beginnt hier die Krux. Der Zwang, wegen
der Darstellung und eventuell anderer Manipulationen auf die Kern-Klassen zurückzugreifen,
schafft Objekte und Klassen von eigenartiger Konsistenz. Einige Beispiele mögen das verdeutlichen.
Beispiel 1: Billardkugel
Es soll eine Billardkugel auf dem
Bildschirm simuliert werden, die an der Bande zurückprallt.
Die OOA
ergibt: |
|
Die Attribute Radius und Farbe sind klar,
Xpos und Ypos speichern die Lage,
SetLink stellt eine Verknüpfung mit dem Tisch her, um den Kontakt mit
der Bande zu prüfen,
Bewegen soll den Lauf der Kugel auf dem Tisch darstellen. |
In einer konsequent objektorientierten Umsetzung würde man unter SuM eine
Klasse mit diesen Attributen und ähnlichen Methoden erwarten. Weit
gefehlt!
In der SuM-Implementierung findet man
unit mKugel;
interface
uses mSuM;
type Kugel = class
hatStift: Stift; // die Kugel
hat einen Stift, um sich zu zeichnen
kenntBildschirm: Bildschirm;//die Kugel
kennt einen Bildschirm als Begrenzung
zRadius : GanzeZahl;
constructor init(pAnfangH, pAnfangV:
GanzeZahl; pGeschwindigkeit: Zahl;
pRichtung: Zahl);
procedure Zeichne;
procedure Loesche;
procedure Bewege;
function hPosition: Zahl;
function vPosition: Zahl;
function Richtung: Zahl;
procedure setzeRichtung(pWinkel:
Zahl);
procedure merke(pBildschirm:
Bildschirm);
destructor gibFrei;
end;
...
[6]
Eine Billardkugel hat in der Realität natürlich
keine Eigenschaften Stift und Bildschirm. Aus der Klassendeklaration geht
auch nicht hervor, auf welche Attribute die Funktionen hPosition, vPosition
und Richtung zugreifen.
Das ist einfach schlecht modelliert und implementiert.
Ein ähnlicher Entwurf
[6a] aggregiert ebenfalls einen
Buntstift und Bildschirm als Attribute:
Beispiel 2: Ampel
Über Ampeln lässt sich
trefflich streiten, denn Abstraktion ist immer ein zielgerichteter
Prozess unter dem Blickwinkel auf einen bestimmten Zweck. Deshalb gibt es
auch Ampelprogramme wie Sand am Meer. Ein Elektroniker, der eine Steuerung
entwickelt, würde vermutlich eine Ampel als abstrakte Einheit sehen, deren
Merkmale lediglich Zustände sind und zu einer Fachklasse kommen, die
keinerlei Bezüge zur physischen Realisation enthält. Hier soll es
jedoch nur um die Art Ampeln gehen, die gern im Anfangsunterricht
programmiert werden und auf dem Bildschirm zu sehen sind, aber auch
richtig funktionieren.
Es ist
allgemein bekannt, wie eine Ampel aussieht und im Prinzip aufgebaut ist:
ein dunkelgrauer Kasten mit drei Lampen drin, die abwechselnd an und
ausgehen.
Die OOA ergibt: |
In der Ampel ist der Typ TLampe aufgeführt, um zu
verdeutlichen, dass es sich um diskrete Komponentenattribute handelt.
|
Das lässt sich mit geeigneten Mitteln und diesen verständlichen Bezeichnern leicht realisieren, wohl nicht unter SuM.
Zum Vergleich ein SuM-Klassendiagramm (aus dem nebenstehenden Quelltext
gezeichnet):
|
unit mAmpel;
interface
uses mSuM,extctrls;
type ampel = class
private
aktuellefarbe : integer;
meinStift : BuntStift;
x,y : zahl;
dieTastatur : Tastatur;
procedure zeichneDich;
public
constructor init(px,py : zahl);
destructor gibfrei;
procedure schalteUm;
function farbe:integer;
function links : zahl;
function rechts : zahl;
function oben : zahl;
function unten : zahl;
end;
... [7] |
Spätestens hier wird das Dilemma mit SuM in voller Schärfe sichtbar:
Eine ordentliche Modellierung scheint nicht möglich, weil das
Ausgangskonzeptes offensichtlich zu solchen Lösungen auffordert und die Sicht auf andere
verstellt. Diese Ampel hat anstelle von drei Lampen, die man ein-
und ausschalten kann, also als Objekte ansprechen kann, eine Tastatur und
einen Buntstift, der etwas auf den Bildschirm malt.
Dieses Beispiel ist nicht etwa ein ausgesucht schlechtes, sondern es
steht exemplarisch für den Charakter der SuM-Objekte, wie sie in den
Schulen gebaut werden. In der zunächst kleinen Welt
von SuM findet man Autos, Züge, die über den Bildschirm fahren. Das ist
alles ordentlich programmiert, aber es ist eine blasse Welt von
Häusern ohne Dach und Fenster, Mäusen ohne Schwanz und Ohren, Lokomotiven
ohne Räder, Kessel und Schornstein usw.
In dem verbreiteten Zug-Projekt werden von einer
Oberklasse Waggon (mit der SuM-typischen Struktur) die Unterklassen Lok, Güterwagen usw. abgeleitet. Wenn
in den Unterklassen lediglich nur eine Methode auftaucht, die per
Stift ein anderes Bild fertigt, aber ansonsten keine Merkmale von
Vererbung zeigt, darf man sich schon fragen, was hier eigentlich
modelliert wird. Sicher nicht Anwendungsaspekte und Ausschnitte der
Realwelt.
SuM bewirkt auf dieser Ebene durch die Restriktionen, dass jedes Objekt prinzipiell
Attribute aus der Kern-Bibliothek haben muss, ein
eigenartiges
Abbild der gefundenen Objekte.
Überspitz könnte man auch
sagen, wer als einziges Werkzeug einen Stift hat, für den besteht die
ganze Welt aus Strichen. Damit wird die Forderung nach sauberer
Modellierung konterkariert und den Schülern vom ersten Tage an ein
falsches Bild von den Entwurfsaufgaben der Informatik und den
Möglichkeiten der OOP vermittelt.
Es steht heute nichts mehr dem im Wege, auch in der Schule ein
objektorientiertes Konzept aus einem Guss in den Unterricht zu
bringen. Das heißt, eine saubere OOA, die notwendigen softwaretechnischen
Erweiterungen in OOD durch Hinzufügen erforderlicher Objekte und Klassen
und am Ende zur Realisierung eine objektorientierte Sprache, die es
erlaubt, das gefundene Modell 1:1 auszudrücken.
Zusammengefasst kann man feststellen dass das SuM-Konzept zwar alle
wichtigen Merkmale von OOP darstellen, aber lediglich die
objektorientierte Programmiertechnik aufzeigen kann, jedoch OOA und
OOD im Anfangsunterricht nicht richtig
unterstützt und so nicht empfohlen werden kann.
Es sollte nicht die prägende Kraft des ersten Eindrucks bei Schülern
und Lehrern unterschätzt werden. Daher scheint es bedenklich, wenn ganzen
Generationen von Lehrern SuM als erster Kontakt zu OOP in dieser Weise beigebracht wird.
Otto Normallehrer wird mit hoher Wahrscheinlichkeit es nicht als Anstoß
verstehen, andere Konzepte zu erarbeiten, sondern dabei bleiben, zumal es
ja so schöne Vorlagen und Materialien gibt. Die Zählebigkeit von SuM und
das daraus entstandene Eigenleben scheinen diese Vermutung zu bestätigen.
Es dient eben inzwischen nicht mehr nur dem Einführungsunterricht, sondern
als Basis-Tool für fast alles, was man so in der Schule programmieren kann. Die Liste der SuM-Derivate für die Klassenstufen
11-13 reicht von 'Abzählreim' bis 'Zahlsuche-Backtracking'.
[8]
4. uGrafik - eine Alternative
Viele Betriebssysteme und
Programmierumgebungen bieten eine
Grafikebene (meist Canvas genannt) an, die Methoden zum
Zeichnen von Linien, Rechtecken usw. hat. Um die oben geschilderten
Probleme zu umgehen und durchgängig objektorientiert zu arbeiten, wurde am
OSZ Handel, Berlin, einer Anregung Monika Seifferts folgend, eine
Grafikbibliothek entwickelt, die entsprechende Klassen enthält[9].
Es liegen Portierungen in
Delphi, Java, Python vor, die in einigen Schulen eingesetzt werden. Die
Klassen sind erweiterbar. Weitere Klassen wie Listen kamen hinzu. Die
Objekte stellen sich selbst auf dem Bildschirm dar und haben alle nötigen
Attribute und Methoden. Sie können mit der Maus angeklickt und verschoben
werden. Kapselung und Geheimnisprinzip sind eingehalten.
Das Paket kann zum gleichen
didaktischen Ansatz im Anfangsunterricht verwendet werden wie SuM, nämlich
- Kennen lernen der
Programmierumgebung,
- objektorientierte Denkweise und Notation,
- zum Benutzen von fertigen Klassen
- bei der Entwicklung eigener Klassen.
Mit einem entscheidenden Unterschied:
Die Schüler arbeiten vom ersten Tage an durchgängig mit Objekten, die
erzeugt und manipuliert werden. Unterrichtssequenzen sind verfügbar[10].
4.1 Billardkugel und Ampel unter uGrafik
Zum Vergleich mit SuM die
Billard- und Ampelklassen mit uGrafik:
Beispiel 1: Billard (s.o.)
UNIT uKugel ;
INTERFACE
(*
==================================================================== *)
USES uGrafik;
type
TKugel = class (TKreis)
XRichtung,
YRichtung : integer;
procedure SetLink(Tisch : TZeichenblatt);
procedure SetXRichtung (xR : integer);
procedure SetYRichtung (yR : integer);
procedure PosVersetzen;
procedure BandePruefen;
procedure Bewegen;
end;
...
TKugel ist eine Unterklasse von TKreis,
welcher Radius, Farbe, Position und die dazugehörigen Zugriffsmethoden
vererbt, sowie Methoden zum Darstellen/Löschen auf dem Bildschirm.
Im FensterFormular wird das Billard gesteuert und dargestellt. Das
Programm (Ausschnitt) erklärt sich selbst.
unit uFenster;
interface
(*
====================================================================
*)
uses
...
uGrafik, // import: TZeichenblatt
uKugel ; // import: TKugel
type
TFensterFrm = class(TForm)
...
end;
var
FensterFrm : TFensterFrm;
Tisch : TZeichenblatt;
WeisseKugel,
GelbeKugel,
RoteKugel : TKugel;
implementation
(*
====================================================================
*)
...
procedure TFensterFrm.FormCreate(Sender: TObject);
(*
--------------------------------------------------------------------
*)
begin
Tisch := TZeichenblatt.Create;
Tisch.SetLink (TischImg);
Tisch.SetFuellFarbe(clGreen);
Tisch.Zeigen;
WeisseKugel := TKugel.Create;
WeisseKugel.SetRadius(15);
WeisseKugel.SetFuellFarbe(clWhite);
WeisseKugel.SetPos(100,200);
WeisseKugel.Setlink(Tisch);
WeisseKugel.Zeigen;
// für die anderen Kugeln das gleiche
end;
procedure TFensterFrm.StartBtnClick(Sender: TObject);
(*
--------------------------------------------------------------------
*)
begin
StopGedrueckt := false;
WeisseKugel.SetXRichtung(3);
WeisseKugel.SetYRichtung(-1);
// für die anderen Kugeln das gleiche
repeat
WeisseKugel.Bewegen;
RoteKugel.Bewegen;
GelbeKugel.Bewegen
until StopGedrueckt;
end;
...
end. |
Beispiel 2: Ampeln
Zur Demonstration der Programmierung mit uGrafik sei hier das gesamte
Programm abgedruckt.
UNIT uLampe;
(* ******************************************************************** *)
(* K L A S S E : TLampe *)
(* -------------------------------------------------------------------- *)
(* Version : 0.9 *)
(* Autor : S. Spolwig, OSZ Handel *)
(* Beschreibung: Die Klasse bildet eine Lampe für beliebige Anwendungen *)
(* ab. *)
(* Compiler : Delphi 5.0 *)
(* Aenderungen : 0.9 11-MAY-01 *)
(* ******************************************************************** *)
INTERFACE
// ======================================================================
uses uGrafik;
type
TLampe = class(TKreis)
public
constructor Create;
procedure Ein;
procedure Aus;
end;
IMPLEMENTATION
// ======================================================================
constructor TLampe.Create;
// --------------------------------------------------------------------
begin
inherited Create;
SetRadius(12);
end;
procedure TLampe.Ein;
// --------------------------------------------------------------------
begin
Zeigen;
end;
procedure TLampe.Aus;
// --------------------------------------------------------------------
begin
Loeschen;
end;
END.
|
UNIT uAmpel;
(* ******************************************************************** *)
(* K L A S S E : TAmpel *)
(* -------------------------------------------------------------------- *)
(* Version : 0.9 *)
(* Autor : S. Spolwig, OSZ Handel *)
(* Beschreibung: Die Klasse bildet eine dumme Ampel mit diskreten *)
(* Lampen ab. *)
(* Compiler : Delphi 5.0 *)
(* Aenderungen : 0.9 11-MAY-01 *)
(* ******************************************************************** *)
INTERFACE
// ======================================================================
uses uGrafik, graphics, uLampe;
type
TAmpel = class(TObject)
private
Kasten : TRechteck;
RoteLampe,
GelbeLampe,
GrueneLampe : TLampe;
XPosition,
YPosition : integer; // wo sie steht
public
constructor Create; // herstellen
procedure RotSchalten;
procedure GelbSchalten;
procedure GruenSchalten;
procedure SetPosition(xp, yp: integer);
procedure Zeigen;
procedure Abschalten;
end;
IMPLEMENTATION
// ======================================================================
constructor TAmpel.Create;
// --------------------------------------------------------------------
begin
inherited create;
Kasten := TRechteck.Create;
Kasten.SetFuellFarbe(clGray);
RoteLampe := TLampe.Create;
GelbeLampe := TLampe.Create;
GrueneLampe := TLampe.Create;
RoteLampe.SetFuellFarbe(clRed);
GelbeLampe.SetFuellFarbe(clYellow);
GrueneLampe.SetFuellFarbe(clLime);
end;
procedure TAmpel.RotSchalten;
// --------------------------------------------------------------------
begin
RoteLampe.Ein;
GelbeLampe.Aus;
GrueneLampe.Aus
end;
procedure TAmpel.GelbSchalten;
// --------------------------------------------------------------------
begin
RoteLampe.Aus;
GelbeLampe.Ein;
GrueneLampe.Aus;
end;
procedure TAmpel.GruenSchalten;
// --------------------------------------------------------------------
begin
RoteLampe.Aus;
GelbeLampe.Aus;
GrueneLampe.Ein;
end;
procedure TAmpel.Zeigen;
// --------------------------------------------------------------------
begin
Kasten.Zeigen;
RoteLampe.Zeigen;
GelbeLampe.Zeigen;
GrueneLampe.Zeigen;
end;
procedure TAmpel.Abschalten;
// --------------------------------------------------------------------
begin
RoteLampe.Aus;
GelbeLampe.Aus;
GrueneLampe.Aus;
end;
procedure TAmpel.SetPosition(xp, yp: integer);
// --------------------------------------------------------------------
begin
XPosition := xp;
YPosition := yp;
Kasten.SetPos(XPosition,YPosition,XPosition + 30,YPosition + 80);
RoteLampe.SetPos((XPosition + 15 ),(YPosition + 15));
GelbeLampe.SetPos((XPosition + 15 ),(YPosition + 40));
GrueneLampe.SetPos((XPosition + 15 ),(YPosition + 65));
end;
END.
|
unit uFenster;
(* ******************************************************************** *)
(* K L A S S E : *)
(* -------------------------------------------------------------------- *)
(* Version : 2.0 *)
(* Autor : S. Spolwig, *)
(* Beschreibung: Die Klasse steuert die Anzeige zweier dummer Ampeln im *)
(* Wechsel an einer Baustelle. *)
(* Zweck : Algorithmen üben bis der Doktor kommt ... *)
(* Compiler : Delphi 5.0 *)
(* Aenderungen : 0.9 11-MAY-01 *)
(* ******************************************************************** *)
INTERFACE
// ======================================================================
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, ExtCtrls,
uGrafik, uZeit, uAmpel;
type
TFensterFrm = class(TForm)
SteuerPnl : TPanel;
EndeBtn : TButton;
BildImg : TImage;
TestBtn : TButton;
AbschaltenBtn : TButton;
procedure FormCreate(Sender: TObject);
procedure TestBtnClick(Sender: TObject);
procedure AbschaltenBtnClick(Sender: TObject);
procedure EndeBtnClick(Sender: TObject);
end;
var
FensterFrm : TFensterFrm;
Ampel_1,
Ampel_2 : TAmpel;
IMPLEMENTATION
{$R *.DFM}
// ======================================================================
var Zeichenblatt : TZeichenblatt;
procedure TFensterFrm.FormCreate(Sender: TObject);
begin
Zeichenblatt := TZeichenblatt.Create;
Zeichenblatt.SetLink(BildImg);
Ampel_1 := TAmpel.Create;
Ampel_2 := TAmpel.Create;
Ampel_1.SetPosition(100,100);
Ampel_2.SetPosition(300,100);
Ampel_1.Zeigen;
Ampel_2.Zeigen;
end;
procedure TFensterFrm.TestBtnClick(Sender: TObject);
// --------------------------------------------------------------------
begin
Ampel_1.Zeigen;
Ampel_2.Zeigen;
Ampel_1.RotSchalten;
Ampel_2.GruenSchalten;
Zeit.SetPause(1000);
Ampel_1.GelbSchalten;
Ampel_2.Gelbschalten;
Zeit.SetPause(1000);
Ampel_1.GruenSchalten;
Ampel_2.RotSchalten;
end;
procedure TFensterFrm.AbschaltenBtnClick(Sender: TObject);
// --------------------------------------------------------------------
begin
Ampel_1.Abschalten;
Ampel_2.Abschalten;
end;
procedure TFensterFrm.EndeBtnClick(Sender: TObject);
// --------------------------------------------------------------------
begin
Close;
end;
end.
|
An diesen einfachen Beispielen wird deutlich, dass der Schwerpunkt des
Unterrichts auf Modellierung und Konfigurieren liegt, während die Zeit
fressende Fummelarbeit der Grafikprogrammierung auf der niedrigen Ebene
entfällt. Durch eine sorgfältige Analyse erreicht man eine hohe
semantische Klarheit der Klassen und ihrer Hierarchie und daraus folgend
i. d. R. eine überraschend einfache Implementierung. Anders ausgedrückt
ist eine saubere OOA das sichere Halteseil beim Gang durch die nach oben
offene Richter-Skala der Komplexität.
4.2 Ein Stift unter uGrafik
Wenn man einmal wirklich einen Stift zum Zeichnen brauchte, ist der sehr
leicht unter uGrafik zu realisieren:
unit uStift;
interface
uses uGrafik;
type
TStift = class (TLinie)
procedure StrichZiehen (ax1,ay1,ax2,ay2 : integer);
end;
implementation
procedure TStift.StrichZiehen (ax1,ay1,ax2,ay2 : integer);
//
--------------------------------------------------------------------
begin
SetPos(ax1,ay1,ax2,ay2);
Zeigen;
end;
end. |
Das ist alles. Der Stift erbt
alles von TLinie und bekommt nur der der schönen Bezeichner wegen eine
(eigentlich überflüssige) Methode 'StrichZiehen'.
4.3 Fachklassen mit Animation
Darüber hinaus können die
Grafikobjekte auch zur Darstellung und Simulation von Anwendungen
eingesetzt werden, die ein ordentliches Fachkonzept aufweisen, z. B. Geld,
Noten, Münzen in einem Geldwechselautomaten, sofern sich die Objekte
selbst auf dem Bildschirm darstellen sollen. Ansonsten ist die Trennung
von Daten und ihrer Repräsentation zu präferieren.
Animierter
Geldwechselautomat
type
TMuenze = class (TBargeld)
protected
Form : TKreis;
Radius : integer;
Praegung : TText;
Farbe : TColor; (* clYellow, Clwhite *)
public
constructor Create; override;
function IstEcht : boolean; override;
...
end;
Aus der Oberklasse TBargeld erbt TMuenze
das Attribut Wert mit den dazugehörigen Zugriffsmethoden.
TMuenze ist Oberklasse für Mark, Groschen, Pfennig usw., die Methoden sind
polymorph. Daneben hat eine Münze die natürlichen Attribute Form und
Prägung zur Darstellung, wobei es schon ein erheblicher Unterschied ist, ob sie als solche
konkretisiert sind oder stattdessen eine technisch erzwungene Kombination
Stift/Bildschirm auftaucht.
Beispiele zur objektorientierten Modellierung mit/ohne
uGrafik stehen stehen unter
http://www.oszhandel.de/gymnasium/faecher/informatik/modellierung/uml.htm
___________________
Literatur und Links
[1] Ludger Humbert: Objektorientierung im
Informatikunterricht der Sekundarstufe II
http://region.Hagen.de/OOP/welcome.html
[2] http://www.learn-line.nrw.de/angebote/oop/medio/sum/kern/index.html
[3] B. Meyer: Objektorientierte Softwareentwicklung. München Wien London,
1990.
[4] http://www.learn-line.nrw.de/angebote/oop/medio/didaktik/bibliothek/index.html
[5] G. Dick: Stifte und Mäuse mit JAVA
http://www.avg-wesel.de/fb/inf/lfb/sumjava/kap5/erstesprogramm.htm
[6] Hannah-Arendt-Gymnasium : Doku Info Lk 12
http://www.kubitz-online.de/oop/uebersicht.html
[6a] http://www.krumwiede.de/Informatik/SumJava/start.html
[7] Hannah-Arendt-Gymnasium : Doku Info Lk
12
[8] http://www.mg-werl.de/faecher/Informatik/Java/index.html
[9] Siegfried Spolwig: 'Hello World' in OOP. IN: LOG IN 19 (1999) Heft 5.
[10] Unterrichtssequenzen mit uGrafik.
http://www.oszhandel.de/gymnasium/faecher/informatik/u-sequenzen/index.htm |