Lose Funktionen oder als Funktion in Klasse

[Uwe Raabe]

Um die globalen Variablen und Funktionen in einer Klasse zu kapseln, ohne davon eine Instanz erzeugen zu müssen, könnte man das so lösen:

Delphi-Quellcode:

type
  TWorkflow = class
  public
  class var
    Variable1: Integer;
    Variable2: Integer;
    Variable3: Integer;
    class function HandleWorkflow1: Boolean;
    class function HandleWorkflow2: Boolean;
    class function HandleWorkflow3: Boolean;
    class function HandleWorkflow4: Boolean;
  end;

Beim Zugriff muss dann immer ein TWorkFlow. davor gestellt werden.

Alternativ geht auch ein record:

Delphi-Quellcode:

type
  TWorkflow = record
  class var
    Variable1: Integer;
    Variable2: Integer;
    Variable3: Integer;
    class function HandleWorkflow1: Boolean; static;
    class function HandleWorkflow2: Boolean; static;
    class function HandleWorkflow3: Boolean; static;
    class function HandleWorkflow4: Boolean; static;
  end;

Wenn man dann noch die Redundanz in den Methodennamen (in der Praxis wohl dann auch bei den Variablen) eliminiert, kommt sowas raus:

Delphi-Quellcode:

type
  TWorkflow = record
  class var
    Variable1: Integer;
    Variable2: Integer;
    Variable3: Integer;
    class function Handle1: Boolean; static;
    class function Handle2: Boolean; static;
    class function Handle3: Boolean; static;
    class function Handle4: Boolean; static;
  end;

[norwegen60]

Hallo zusammen,

da ich in einem Programm/DLL nur eine Instanz der Klasse benötige, habe ich so was perverses wir Delphi gemacht und das noch getoppt


ich habe so was

Delphi-Quellcode:

interface

type
  THandleWorkflow = Class
  private
    FVariable1 : Integer;
    FVariable2 : Integer;
    FVariable3 : Integer;

    procedure GetVariable2: Integer;
    procedure GetVariable3: Integer;
    procedure SetVariable3(const Value: Integer);
  public
    property Variable1 : Integer read FVariable1 write FVariable1;
    property Variable2 : Integer read GetVariable2 write FVariable2;
    property Variable2 : Integer read GetVariable3 write SetVariable3;

    constructor Create;
    destructor Destroy; override;

    function HandleWorkflow1: Boolean;
    function HandleWorkflow2: Boolean;
    function HandleWorkflow3: Boolean;
    function HandleWorkflow4: Boolean;
  end;

var
  HandleWorkflow :THandleWorkflow ;

implementation




initialization

HandleWorkflow := THandleWorkflow .Create;

finalization

HandleWorkflow .Free;

end.

Ich habe nie ganz verstanden, warum das so schlimm ist wenn man sicher nur eine Instanz braucht

Dass ich Variablen nicht als public anlege sondern als property ist zur Gewohnheit geworden

Das class function HandleWorkflow1: Boolean; erschließt sich mir nicht ganz. Ich hätte gesagt, dass es letztlich das gleiche ist wie ich es mit initialize und finalization mache

Ich habe jahrelang so eine Klasse wie oben - aber nur mit procedure udn function - ohne Create und Free benutzt. Ohne Probleme.

Grüße
Gerd

[Uwe Raabe]

Zitat von norwegen60:

Ich habe jahrelang so eine Klasse wie oben - aber nur mit procedure udn function - ohne Create und Free benutzt. Ohne Probleme.

Natürlich, und das ist ja auch nicht falsch. Wir zeigen hier lediglich andere Wege auf.

[Edelfix]

Zu "Über [Ctrl + C] wird Funktionsblock und FVariablen automatisch angelegt" habe ich eine Frage.

Es wird jedes mal eine Set Procedure angelegt. Lässt sich das ausschalten?

[DeddyH]

Nicht, dass ich wüsste. Aber wenn man etwas mehr tippt:

Delphi-Quellcode:

...
property Blubb: integer read FBlubb write FBlubb;

dann wird auch kein Setter angelegt.

[Uwe Raabe]

Oder man verwendet das propf Template (oder MMX).

[jaenicke]

Ein Vorteil der Kapselung in Klassenmethoden ist, dass man sofort sieht, wo eine Methode herkommt. Wenn man also Code kopiert oder den Code restrukturiert, ist es so deutlich einfacher. Hat man nur eine einzelne Methode, die der Compiler nicht findet, ist diese schlechter zu finden.

Natürlich könnte man auch immer den Unitnamen davonschreiben, aber das wäre dann optional. Den Klassennamen kann man hingegen nicht weglassen, womit sichergestellt ist, dass das auch jeder im Team macht.

[himitsu]

"ohne Create" ... erstmal muß man dann eine Variable benutzen,
während man bei Class-Proicedure direkt den Typ nehmen kann.

Und so lange du auf nichts von der Klassen-Instanz zugreifst (z.B. Felder/Variablen), also das Self nie benutzt wird, dann gibt es auch keine Fehler, egal ob die Variable NIL oder sonstwie uninitialisiert (zufällig) ist.



Vorteil von Record statt Class ... man muß sich keine Gedanken um das Create machen, und vor allem auch nicht um das Free/Destroy.



Vorteil von Class-Constructor gegenüber Initialization, also für gesharetem Code (wäre schön, wenn es Emba mal nutzen würde),
dass bei Nichtbenutzung der Klasse sie auch garnicht erst einkompiliert gelinkt wird.

Steht der Create-Code in der Initialization, dann wird dadurch immer die Klasse "benutzt", auch wenn sie niemand nutzt.

[Uwe Raabe]

Am Ende sind solche class var bzw. class function (insbesondere wenn auch noch static) auch nichts anderes als globale Variablen bzw. Methoden. Es ändert sich lediglich die Syntax des Zugriffs.

Die Namensgebung wird auch etwas einfacher (obwohl die ja nie einfach ist), da man mit dem Klassennamen als Präfix eine gewisse Kapselung erhält, die bei echten globalen Variablen und Methoden ja nur über die Namensgebung erreicht werden kann. Wer hat nicht schon darüber geflucht, dass mit dem Einfügen einer Unit in die uses-Anweisung plötzlich eine gleichnamige Variable oder Methode im Scope weiter vorne steht und bestenfalls vom Compiler bemängelt wird. Die Lösung des Voranstellen des Unitnamens wird mit dem class/record Ansatz in der Regel überflüssig.

Nebenbei: Ist das nicht lästig, wenn man solche mit Unitnamen qualifizierte Zugriffe im Code hat und die Unit dann plötzlich nicht mehr Sysutils oder Windows, sondern System.Sysutils oder Winapi.Windows heißt. Da helfen die Unit-Scope-Names nämlich auch nicht.

[Blup]

Mir scheint wichtiger wie man auf solche globalen Resourcen zugreift.

Ich schotte den Anwendungsfall durch ein Provider von der Anwendungsumgebung ab.
Das kann eine abstrakte Klasse sein oder ein Interface, das den Zugriff kapselt.
Darüber werden alle vom Anwendungsfall benötigten globalen Funktionen, Methoden, Interfaces und Variablen bereitgestellt.

In der Anwendung werden die Zugriffe einfach nur durchgereicht.
Im Testfall kann eine ganz konkrete Umgebung simuliert werden (Mock).

Der Überblick über die Abhängigkeiten erleichtert auch die Aufwandschätzung und Realisierung von Erweiterungen oder
Migration eines Anwendungsfalls (z.B. Kommandozeile, Dienstprogramm, Webservice usw.).