liege ich richtig mit dem OOP-Versuch

[Der schöne Günther]

Zitat von EdAdvokat:

Die Methoden, auf die die Propertys zugreifen (hier setLaenge, setBreite und GetFlaecheninhalt) lassen sich nicht in private oder protect verstecken.

Natürlich lassen sie sich das. Woran genau soll es scheitern?

Zitat von EdAdvokat:

Sollte man also immer "destructor ....Destroy" einsetzen?

Im Gegensatz zu anderen Sprachen hat der Destruktor in Delphi einen Namen. Man kann ihn nennen wie man will, sollte es aber wirklich nicht tun. Alle (bis auf dieses Tutorial) nennen ihn "destroy".

Der Grund weshalb man davon nicht abweichen sollte deckt sich mit deiner nächsten Frage

Zitat von EdAdvokat:

Warum "override " was überschreibe ich da?

Jede Klasse die du in Delphi definierst leitet sich implizit von der Ur-Klasse TObject ab. TObject hat einen Destruktor mit dem Namen "Destroy". Wenn ein Objekt deiner Klasse zerstört werden soll müssen alle Destruktoren die ganze Vererbungshierarchie hinauf abgearbeitet werden bis man bei TObject ankommt.

Der Destruktor von TObject ist "virtuell". Das bedeutet dass Unterklassen (z.B. deine) das Verhalten von "Destroy" abändern können. In deinem Fall zählt es die Klassenvariable "Anzahl" eins herunter damit man sieht dass es in der Welt nun eine Fläche weniger gibt. Doch hiernach muss im Destruktor noch "inherited" aufgerufen werden damit der Destruktor von TObject aufgerufen wird. Das fehlt in deinem Tutorial ebenfalls, das ist falsch.

Schau mal zu Themen wie "Vererbung" und "Polymorphie". Liest sich vielleicht beim ersten mal etwas wild, aber eigentlich ist es ganz einfach.


Als absolute Kurzfassung, so wäre das Tutorial korrekt:

Delphi-Quellcode:

interface

type
   TFläche = class // Man kann auch "TFläche = class(TObject)" schreiben
      public
         destructor Destroy(); override;
   end;
   

implementation

destructor TFläche.Destroy();
begin
   // Tue etwas
   inherited;
end;

[TBx]

Das Tutorial ist überarbeitungsbedürftig. Ich habe es auf meine ToDo-Liste gesetzt.

[EdAdvokat]

Danke für die Hinweise zum Destructor. Werde ich mir nochmals in Ruhe ansehen.
Warum sich bestimmte Methoden nicht verbergen lassen liegt im konkreten Fall daran, dass im Formular diese Methoden aufgerufen werden und wenn sie nicht
public sind, geht es nicht. Was könnte ich dagegen tun? Ich habe erkenntlich TForm in eine unit und TFlaecheninhalt in eine weitere unit gepackt. TForm-Methoden(Buttonclick...) greifen auf GetFlaecheninhalt beispielsweise zu :

Delphi-Quellcode:

procedure TForm1.BerechneFlClick(Sender: TObject);
begin
  Flaecheninh.setLaenge(strtoint(Laenge.text));
  Flaecheninh.setBreite(strtoint(Breite.text));
  LbFlaecheninhalt.Caption:=inttostr([B]Flaecheninh.GetFlaecheninhalt[/B]);
end;

Das ist mein kleines Problem. Oder muss ich damit leben?

[TBx]

Greif nicht auf die Methoden sondern auf das Property zu. Dafür ist das ja da.

[Luckie]

So hätte ich es gemacht:

Delphi-Quellcode:

Type
  TRechteck = class(TObject)
  private
    FLaenge: double;
   FBreite: double;
   FFlaeche: double;
   FUmfang: double;
    procedure BerechneFlaeche: Double;
    procedure BerechneUmfang: Double;
   procedure SetLaenge(laenge: double);
   procedure SetBreite(breite: double);
  public
   Property Laenge: Double write SetLaenge;
   Property Breite: Double write SetBreite;
    Property Flaeche: Double read FFlaeche;
    Property Umfang: Double read FUmfang;
  End;
  
  procedure TRechteck.SetLaenge(laenge: double);
  begin
    // ToDo:
   // wenn kleiner 0 -> Exception auslösen "Länge darf nicht kleiner 0 sein"
   // oder besser allgemeine Exception InvalideArgument
   laenge := FLaenge;
  end;
  
  procedure TRechteck.SetBreite(breite: double);
  begin
    // ToDo:
   // wenn kleiner 0 -> Exception auslösen "Breite darf nicht kleiner 0 sein"
   // oder besser allgemeine Exception InvalideArgument
   breite := FBreite;
  end;
  
  procedure TRechteck.BerechneFlaeche;
  begin
    FFlaeche := FLaenge * FBreite;
  end;
  
  procedure REechteck.BerechneUmfang;
  begin
    FUmfang := (2 * FLaenge) + (2 * FBreite);
  end;
  
///////////////////////////////////////////////////////////////////////////////

  procedure TForm1.BerechneFlClick(Sender: TObject);
  var
    TRechteck: Rechteck;
   Flaeche: double;
  begin
    Rechteck := TRechteck.Create;
   try
     // Eingaben validieren, wenn valid dann:
     Rechteck.Laenge := ...;
     Recheck.Breite := ...;
     Flaeche := Rechteck.Flaeche;
   finally
     Recheckt.Free;
   end;
  end;

Wozu der Zähler? Wenn jemand mehrere Flächen berechnen will, dann soll er das selbst implementieren.

Aber du scheint das Prinzip der Objektorientierung noch nicht so ganz verstanden zu haben:

Delphi-Quellcode:

Type
  TFlaeche = class(TObject)
  private
  protected
    Function BerechneFlaeche: Double; virtual; abstract;
    Function BerechneUmfang: Double; virtual; abstract;
  public

Du willst anscheinen eine allgemeine Klasse schreiben, um Fläche und Umfang verschiedener geometrischer Körper zu berechnen. Und die Kind-Klassen sollen dann BerechneFlaeche und BerechneUmfang selbst implementieren. Idee gut. Aber Namensgebung schlecht. Die Klasse heißt TFlaeche. Warum berechnet eine Klasse TFlaeche den Umfang?

TGeometrischerKoerper = class(TObject) TRechteck = class(TGeometrischerKoerper) TDreieck = class(TGeometrischerKoerper)

[Der schöne Günther]

Zitat von Luckie:

Wozu der Zähler? Wenn jemand mehrere Flächen berechnen will, dann soll er das selbst implementieren.

Ich glaube das klassische Beispiel für Klassenvariablen. Klar kann man sich über den Sinn streiten, aber ich finde das als Beispiel ganz gut.

[SProske]

Zitat von Luckie:

Delphi-Quellcode:

  public
    Property Laenge: Double write SetLaenge;
    Property Breite: Double write SetBreite;
    Property Flaeche: Double read FFlaeche;

Wieso Länge und Breite als write only?
Und müsste die Property Flaeche nicht als read-procedure das BerechneFlaeche bekommen?

Zitat von Luckie:

Delphi-Quellcode:

  
  procedure TRechteck.SetLaenge(laenge: double);
  begin
    // ToDo:
   // wenn kleiner 0 -> Exception auslösen "Länge darf nicht kleiner 0 sein"
   // oder besser allgemeine Exception InvalideArgument
   laenge := FLaenge;
  end;

Sollte die Zuweisung nicht genau andersherum erfolgen?
Ist es eine gute Idee, den Parameter der Set-Procdure genau so zu nennen, wie die Property - irgendwann fängt man dann doch an zu überlegen, was von beiden eigentlich grad angesprochen wird.

[EWeiss]

Zitat:

Sollte die Zuweisung nicht genau andersherum erfolgen?

nein.. sorry da nur schreibzugriff
ja war quatsch von mir

gruss

[Luckie]

Ja natürlich andersherum. Sie heißen doch unterschiedlich.

Zitat:

Wieso Länge und Breite als write only?

OK, kann man drüber streiten, ob die Klasse auch die Eingabewerte wieder zurückgeben können soll. Weil die weiß ich ja, sonst hätte ich die Klasse ja gar nicht nutzen können.

Zitat:

Und müsste die Property Flaeche nicht als read-procedure das BerechneFlaeche bekommen?

Nein. Die private Prozedur zum Berechnen der Fläche legt das Ergebnis in FFlaeche ab.

[Luckie]

Unterschiedliche Namen:

Delphi-Quellcode:

 procedure TRechteck.SetLaenge(laenge: double);
  begin
    // ToDo:
   // wenn kleiner 0 -> Exception auslösen "Länge darf nicht kleiner 0 sein"
   // oder besser allgemeine Exception InvalideArgument
   FLaenge := laenge;
  end;

Der Parameter heißt laenge das Attribut FLaenge.

Delphi-Quellcode:

  procedure TRechteck.BerechneFlaeche;
  begin
    FFlaeche := FLaenge * FBreite;
  end;
  
  
  // Aufruf im Formular
  Flaeche := Rechteck.Flaeche;

Flaeche ist die private variable und Rechteck.Flaeche ist das Attribut Flaeche des Objektes Rechteck. Nix gleich.

Wie gesagt, man kann drüber streiten. Aber wenn du eine gescheite Datenhaltung machst, sollte es kein Problem sein an die Werte zu kommen. Wie gesagt, du musst sie ja selber wissen, wenn du die Klasse nutzen willst.


PS: War alles nur ins Notepad++ gehackt. Ich übernehme keine Gewähr für nichts.