[Erledigt] Verständnisfrage zu Klassen

[MacWomble]

Ist das Init für Klassen 'Pflicht' oder 'Guter Stil', oder genügt es wenn man die Propertis mit Defaults bestückt, wo notwendig?
Was, außer der Startzuweisung sollte in der Init erfolgen?

(Endlich fange ich mal mit Klassen an )

[m.fuchs]

Init? Du meinst den Konstruktor? Der wird im Allgemeinen als Create benannt.

Wenn du keine Initialisierung vornehmen musst, dann kannst du ihn dir sparen. Das ist völlig legitim und auch kein schlechter Stil.

Reinpacken tust du halt alles, was zum erstmaligen Nutzen eines Objektes nötig ist: Default-Daten in die einzelnen Felder packen, Unterobjekte erstellen, sonstewas.
Wenn du ein konkretes Beispiel hast, kann man es sicher auch besser erklären.

[MacWomble]

Danke für die Info, das hilft weiter.
Ich meinte Init, weil ich das in einem Delphi.Beispiel gesehen habe. Create ist klar.
Dann bastel ich jetzt mal weiter - fängt so langsam an, Spass zu machen ...

[m.fuchs]

Kleiner Tipp: Wenn du einen Konstruktor schreibst, setze in die erste Zeile

Code: Alles auswählen

inherited Create;

Damit wird der Kontruktor der Elternklasse aufgerufen. Das ist zwar beim Standardfall (der Ableitung von TObject) nicht notwendig, aber man kann dann später leichter die Elternklassen ändern.

[wp_xyz]

Ist das Init für Klassen 'Pflicht' oder 'Guter Stil', oder genügt es wenn man die Propertis mit Defaults bestückt, wo notwendig?
Was, außer der Startzuweisung sollte in der Init erfolgen?

(Endlich fange ich mal mit Klassen an )

Meinst du "object" oder "class"?

Init? Du meinst den Konstruktor? Der wird im Allgemeinen als Create benannt.

Wenn du keine Initialisierung vornehmen musst, dann kannst du ihn dir sparen. Das ist völlig legitim und auch kein schlechter Stil.

Das geht schief, wenn "class" gemeint ist. Klassen (also z.B. type TMyClass = class) werden auf dem Heap angelegt, und die Speicherreservierung erfolgt im Konstructor. Kein Aufruf von Create -> keine Speicher -> crash.

Code: Alles auswählen

type
  TMyObject = class
    A: Integer;
  end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  obj: TMyObject;
begin
  obj.A := 1;  // <--- crash here!
end; 

Die älteren Objekte (also: TMyObject = object) dagegen liegen auf dem Stack und kommen ohne Konstruktor aus, sofern keine virtuellen Methoden deklariert sind, denn der Aufbau der VMT (virtuelle-Methoden-tabelle) erfolgt wieder im Konstructor.

[m.fuchs]

Init? Du meinst den Konstruktor? Der wird im Allgemeinen als Create benannt.

Wenn du keine Initialisierung vornehmen musst, dann kannst du ihn dir sparen. Das ist völlig legitim und auch kein schlechter Stil.

Das geht schief, wenn "class" gemeint ist. Klassen (also z.B. type TMyClass = class) werden auf dem Heap angelegt, und die Speicherreservierung erfolgt im Konstructor. Kein Aufruf von Create -> keine Speicher -> crash.

Es ging aber nicht um den Aufruf von Create, sondern ob in einer abgeleiteten Klasse eine implementiert werden muss. Und das muss eben nicht sein.

[MacWomble]

Bevor ihr euch die Köpfe abreisst:

Ich habe mir im Moment folgende die angehängte Unit erstellt. Ich habe Create auch angelegt, aber es ging um das tatsächlich um das Init.

Aber ich habe dennoch eine Frage dazu:

Wenn ich es richtig verstanden habe, sollten Methoden, welche auf die DB zugreifen (um das Objekt zu füllen bzw zu speichern etc.), in eine eigene Unit. Habe ich das richtig verstanden?

[wp_xyz]

Es ging aber nicht um den Aufruf von Create, sondern ob in einer abgeleiteten Klasse eine implementiert werden muss.

So explizit steht das nirgendwo. Die Formulierungen hier im Forum sind meistens so, dass sie mindestens zwei Interpretationen zulassen.

[compmgmt]

@MacWomble Tipp: die ganzen Get und Set Funktionen kannst du dir auch sparen wenn sie nichts anderes machen außer lesen und schreiben.
Folgendes funktioniert auch wunderbar:

Code: Alles auswählen

TMyClass = class
  private
    FId: Integer;
  public
    property Id: Integer read FId write FId;

Nur wenn du durch das Ändern einer property auch andere Dinge ändern musst benötigst du ein Set Funktion. Eine Get Funktion benötigt man eher selten, kommt aber vor. Ebenso kannst du den "write" Aspekt weglassen und dadurch eine nur lesbare Eigenschaft erzeugen, falls du das mal benötigst.

Als Beispiel nehme ich mal einen Auszug aus meinem aktuellen Projekt, bei dem ich u.a. einen Server schreibe. Der zugehörige Client überträgt beim Verbinden seine Version und der Server kann schauen ob diese Version überhaupt unterstützt wird oder ob sie gar zu alt ist und den Client darauf rausschmeißen:

Code: Alles auswählen

type
  TQuery = class
    private
      FVersion: AnsiString;
      ...
    protected
      function IsVersionSupported: Boolean; virtual; // In dieser Methode wird evaluiert ob FVersion noch unterstützt wird
      ...
    public
      property Version: AnsiString read FVersion write FVersion; // Die Version wird direkt in die Variable FVersion geschrieben bzw daraus gelesen
      property VersionSupported: Boolean read IsVersionSupported; // Das ist eine Read-Only Eigenschaft die mir sagt ob die Version des Clients unterstützt wird
      ...

[MacWomble]

Ok, vielen Dank. Das habe ich nun auch verstanden. Macht mir die Sache wesentlich einfacher und übersichtlicher !