Seite 1 von 1

Function/Sub oder Klassen?

BeitragVerfasst: Mo 22. Mär 2010, 15:34
von Bernd Gilles
Grundsatzfrage: Packen wir Hilfsroutinen in Function's (Sub's) oder muss es immer eine Klasse sein?
Wenn ich mir z.B. das Thema "Registry" vornehme, könnte man natürlich auf die Idee kommen das Ganze in eine schöne Klasse WinRegistry o.ä. zu verpacken.
Andersrum hat's aber auch einen gewissen Charme, den Zugriff ganz klassisch mittels Funktionen zu regeln, da ich zum Lesen eines einzelnen Wertes aus der Registry so keine Instanz erzeugen muss.

Beispiel aus dem Delphi-Umfeld:
Im Standard-Delphi benötige ich eine Instanz der Klasse "TRegistry".
Dann muss ich den benötigten Registry-Key (HKEY_CURRENT_USER etc.) öffnen und kann dann einen Wert lesen.
Code: Alles auswählen
var
  r: TRegistry;
  x: Integer;
begin
  r := TRegistry.Create;
  try
    if r.OpenKey('Software/CodeLib') then
    begin
      x := r.ReadInteger('Version');
      r.CloseKey;
    end;
  finally
    r.Free;
  end;
end;

Das Projekt JEDI kapselt das in kleine knackige Funktionen:
Code: Alles auswählen
x = RegReadInteger(HKCU, 'Software/CodeLib', 'Version')

Ich persönlich halte nicht viel davon, alles unbedingt immer und überall in Klassen zu packen (auch wenn's noch so viel OOP und total hipp ist).

Was meint ihr?

Re: Function/Sub oder Klassen?

BeitragVerfasst: Mo 22. Mär 2010, 16:08
von Josef Pötzl
In meinen Anwendungen kommt meistens eine Mixtur aus beiden Varianten zum Einsatz. Wenn es mehrere ähnliche Prozeduren zusammengefasst werden sollen, bin ich durchaus ein Freund von Klassen, die man dann z. B. wie DoCmd nutzt. Andererseits erstelle ich wiederum oft ein Modul, dass mir den Zugriff auf einige Klassenmethoden abkürzt. Meistens stecke ich einfache eigenständige Prozeduren in allgemeine Module und nutze sie wie VBA-Funktionen.

Beispiel: file/modFiles.bas
Diese Prozeduren könnte man auch in eine Klasse stecken und die Klasse einmal für die Anwendung instanzieren, so wie ich es für die Klasse base/ApplicationHandler.cls im Modul base/modApplication.bas mache.

Klassen sind meiner Ansicht nach allerdings für Erweiterungen besser geeignet, da man über Ereignisse eine relativ flexible Schnittstelle in VBA realisieren kann.
Andererseits könnte man ein bestehendes Modul immer noch zu einer Klasse umgestalten, falls Bedarf besteht.
Soll heißen: ich würde mich nicht nur auf Klassen festlegen wollen, da auch ein übersichtliches Modul seine Vorteile hat (z. B. Einsatz der Funktionen in Jet-Abfragen).

mfg
Josef

[OT]
Bezüglich ApplicationHandler-Klasse: viewtopic.php?p=8#p8