Schritt für Schritt zur klassenbasierten Programmierung - Teil 3

[fliegermichl]

In diesem Beitrag hatte Theo einen Link zu einer Einführung in OOP gepostet. Dort werden als praktisches Beispiel geometrische Objekte als Klassen definiert.
Das ist eine gute Idee und ich würde das gerne aufgreifen.

Wir nehmen uns vor, eine einfach 2D CAD Anwendung zu programmieren.
Allen CAD Objekten gleich ist, daß sie eine Bezeichnung, eine Farbe sowie eine X und eine Y Position am Bildschirm haben sollen.
Man könnte das so definieren.

Code: Alles auswählen

type
  TGeo = class
    Bezeichnung : string;
    Farbe : TColor;
    x, y : integer;
  end;

Diese Variablen werden bei Klassen Felder genannt.
Da man anhand der Bezeichner nicht erkennen kann, ob es sich um Felder handelt, hat sich eingebürgert, daß diesen immer ein f vorangestellt wird.
Sieht dann also jetzt so aus:

Code: Alles auswählen

type
  TGeo = class
    fBezeichnung : string;
    fFarbe : TColor;
    fx, fy : integer;
  end;

Nun sollen CAD Objekte ja auch gezeichnet werden können. Dazu soll zunächst die aktuelle Stiftfarbe und Position gesichert werden, Dann soll sich das Geoobjekt darstellen und
danach die gesicherte Farbe und Position wieder hergestellt werden.

Damit kommen die sogenannten Methoden ins Spiel. Methoden sind Prozeduren und Funktionen die zu einer Klasse definiert werden und automatisch immer einen unsichtbaren Parameter self bekommen, welcher auf die Instanz der Klasse verweist. Methoden können immer auf die Felder zugreifen. Der Compiler sorgt dafür, daß es immer die richtigen sind. Um die Stiftfarbe und Position sichern zu können, definieren wir zwei neue Felder fSavePos und fSaveColor sowie 3 Methoden zum sichern, Darstellen und restaurieren.

Code: Alles auswählen

type

  { TGeo }

  TGeo = class
    fBezeichnung : string;
    fFarbe : TColor;
    fx, fy : integer;
    fSaveColor : TColor;
    fSavePosition : TPoint;
    procedure SaveCanvas(Canvas : TCanvas);
    procedure Draw(Canvas : TCanvas); virtual; abstract;
    procedure RestoreCanvas(Canvas : TCanvas);
  end;

implementation

{ TGeo }

procedure TGeo.SaveCanvas(Canvas: TCanvas);
begin
  fSaveColor := Canvas.Pen.Color;
  fSavePosition := Canvas.PenPos;
end;

procedure TGeo.RestoreCanvas(Canvas: TCanvas);
begin
  Canvas.Pen.Color := fSaveColor;
  Canvas.PenPos := fSavePosition;
end;

Zu den Methoden SaveCanvas und RestoreCanvas gibt es glaube ich nicht viel zu erklären. Die erste bekommt eine Variable der Instanz einer TCanvas Klasse und sichert deren Stiftfarbe sowie Position in den neuen Feldern und RestoreCanvas macht genau das Gegenteil.

Aber was hat es mit dieser ominösen Draw Methode auf sich?

TGeo ist eine Basisklasse, welche einige grundlegende Dinge festlegt, nämlich, daß sie einen Namen, eine Position und eine Farbe hat sowie die Stiftfarbe und Position sichern und wiederherstellen kann, mehr aber auch nicht.
Die Definition von

Code: Alles auswählen

procedure Draw(Canvas : TCanvas); virtual; abstract; 

besagt, daß von TGeo abgeleitete Klassen diese Methode zwingend implementieren müssen.

Wenn man eine Variable vom Typ TGeo definiert und myGeo := TGeo.Create aufruft, bekommt man vom Compiler eine Warnung, daß eine Klasse mit abstrakten Methoden erzeugt wird. Wird diese abstrakte Methode dann tatsächlich aufgerufen, dann kommt es zu einem Laufzeitfehler.

Man könnte diese Methode auch ohne das Schlüsselwort abstract deklarieren. In dem Fall muß die Methode aber auch schon in der Basisklasse implementiert werden.
Dabei kann es eine leere Methode sein.
Man kann also sagen, wenn Methoden dafür vorgesehen sind, von abgeleiteten Klassen überschrieben zu werden, dann werden sie mit virtual definiert.
Häufig werden virtuelle Methoden sowohl in der Basisklasse als auch in den abgeleiteten Klassen verwendet und überschrieben. Ein Beispiel dafür folgt später bei den Defaulteinstellungen.

[corpsman]

Und schon wieder muss ich rummäckeln

Code: Alles auswählen

   procedure Draw(Canvas : TCanvas); virtual; abstract;

Leitet man das Object ab und ruft Draw auf, dann bekommt man einen Abstrakten Fehler.
Ich persöhnlich finde diese "Variante" besser, weil die Fehlermeldung deutlicher ist.

Code: Alles auswählen

   procedure Draw(Canvas : TCanvas); virtual; 
..   
implementation

procedure TGeo.Draw(Canvas : TCanvas); 
begin
  raise exception.create('Error: ' + Classname+'.draw not implemented.');
end;

[wp_xyz]

Ich persöhnlich finde diese "Variante" besser, weil die Fehlermeldung deutlicher ist.

Ich nicht. Denn bei "abstract" kann der Compiler schon vorher eine Warnung ausgeben. Zugegeben, die Fehlermeldung ist für den Einsteiger absolut unverständlich, aber wenn man das einmal mitgemacht hat, weiß man, worum es geht...

[PascalDragon]

Außerdem kann man durch Verwendung von {$warn constructing_abstract error} dafür sorgen, dass der Compiler einen Fehler generiert, wenn du eine Klasse erzeugst, die eine abstrakte Methode enthält (außer man macht dies über eine Klassenvariable):

Code: Alles auswählen

program tabstract;

{$mode objfpc}{$H+}
{$warn constructing_abstract error}

type
  TTest = class
    procedure Test; virtual; abstract;
  end;

  TTest2 = class(TTest)
  end;

var
  t: TTest;
begin
  t := TTest.Create;
  t := TTest2.Create;
end.

[pluto]

Außerdem kann man durch Verwendung von {$warn constructing_abstract error} dafür sorgen, dass der Compiler einen Fehler generiert, wenn du eine Klasse erzeugst, die eine abstrakte Methode enthält (außer man macht dies über eine Klassenvariable):

Warum macht der Kompiler das nicht Automatisch von sich aus?

[PascalDragon]

Außerdem kann man durch Verwendung von {$warn constructing_abstract error} dafür sorgen, dass der Compiler einen Fehler generiert, wenn du eine Klasse erzeugst, die eine abstrakte Methode enthält (außer man macht dies über eine Klassenvariable):

Warum macht der Kompiler das nicht Automatisch von sich aus?

Rückwärts- und Delphikompatibilität.