Klassen verwalten, wie macht ihr das? Was ist sinnvoll?

[jaenicke]

Zitat von BAMatze:

@jaenicke: Also das hört sich ziemlich gut schonmal an, kannte ich so noch nicht. Wie verwaltest du deine einzelnen Quellcode dann ansich? Hast du sie einzeln in Pas-Dateien gelagert?

Ich habe zum einen Bibliotheksunits, die tatsächlich nur viele Funktionen beinhalten, z.B. zum Suchen von Dateien und Ordnern in einem Ordner und so etwas.

Und dann habe ich auch Units mit Klassen zur Kapselung von Objekten wo das sinnvoller ist. Und bei dem Projekt mit den Einstellungen sind es natürlich auch Klassen, die abgeleitet und verwendet werden. (Dieses Projekt stelle ich gerade zur Veröffentlichung fertig.)

Zitat von BAMatze:

würde hier eine DLL oder so Sinn machen? Die scheinen ja so ähnlich zu funktionieren, wie die Header-Dateien in C/C++

Headerdateien geben an welche Funktionen usw. in einer DLL oder C-Datei drin sind. Si etwas gibt es in Delphi nicht. Da muss man normale Units zur Einbindung von DLLs benutzen.

Die Einbindung von DLLs ist grundsätzlich nicht schlecht, aber langsamer als die direkte native Einbindung. Zudem müsstest du die DLLs auch ständig mitliefern...

[Phoenix]

Zitat von BAMatze:

@all: auch wenn die Frage vieleicht etwas komisch klingt, aber da ich mich noch nicht so damit beschäfftigt habe, außer vorhandene zu verwenden, würde hier eine DLL oder so Sinn machen? Die scheinen ja so ähnlich zu funktionieren, wie die Header-Dateien in C/C++ und da ich dort mal Info-Unterricht drin hatte, weiß ich unser Lehrer hat für sich eigene Header-Dateien geschrieben, wo viele Funktionen drin lagen, die er häufig verwendet hat.

Kommt drauf an. Funktionieren würde das schon.

Das Problem ist eher, dass Du dann a) diese DLL immer mit ausliefern muss und b) Du dennoch für jedes Projekt was diese DLL nutzt die Funktionen aus der DLL importieren musst (in aller Regel Durch eine Unit, die diese Funktionen anderen Units zur Verfügung stellt).

Das heisst, für Deinen Entwicklungsaufwand ändert sich nichts. Du musst dennoch die benötigten Funktionen in einer .pas-Datei in alle Projekte einbinden. Nur wenn Du diese Funktionen änderst / korrigierst reicht es dann aus, die DLL auszutauschen und Du musst Deine Projekte nicht alle neu erstellen.

Wenn Du das nicht benötigst, dann kannst Du die Funktionen genausogut gleich direkt in Deine Projekte einkompilieren lassen - indem Du diese Unit direkt einbindest.

[Luckie]

C/C++ Header-Dateien und DLLs sind absolut unterschiedliche Konzepte aus unterschiedlichen Bereichen. DLLs enthalten kompilierte Funktionen die alleine nicht lauffähig sind, aber von Prozessen geladen und genutzt werden kann.

Header-Dateien sind nur die Schnittstelle zu den Quellcodedateien. In ihnen befinden sich nur die Funktionsdeklarationen.

Sammelst du deine Funktionen in DLLs handelst du dir nur ünnötige Probleme ein: Übergabe von Strings ist problematisch sowie die übergabe von Objecten und der Gleichen.

[BAMatze]

Zitat von Tyrael Y.:

Es geht um reine Prozeduren und Funktionen, die du künstlich in Klassen integrierst?

Es handelt sich teilweise um kleine einfache Proceduren und Funktionen. Ich geb mal hier ein kleine Beispiele das ich derzeit in einer Pas-Datei (Hilfsfunktionen.Pas) habe. Habe die derzeit jeweils als eine Class behandelt. Dann wisst ihr zumindest, was ich meine.

Hier das erste Beispiel:

Delphi-Quellcode:

Type TDLL_Datei = class
  private
    bDLL_vorhanden: boolean;
    sDLLName: string;
    hDLLHandle: THandle;
    function DLL_vorhanden: boolean;
  public
    constructor create(const sDateiName: string); reintroduce;
    destructor Destroy; override;
    property Vorhanden: boolean read bDLL_vorhanden;
    property Handle: THandle read hDLLHandle;
end;

implementation

constructor TDLL_Datei.Create(const sDateiName: string);
begin
  inherited create;
  sDLLName := sDateiName;
  bDLL_vorhanden := DLL_vorhanden;
end;

function TDLL_Datei.DLL_vorhanden: boolean;
var DLL_Handle: THandle;
begin
  try
    DLL_Handle:=LoadLibrary(PChar(ExtractFilePath(ParamStr(0))+ 'DLL\'+sDLLName));
    if DLL_Handle <> 0 then
      begin
        hDLLHandle := DLL_Handle;
        result := true;
        FreeLibrary(DLL_Handle);
      end
    else result := False
  except
    result := false;
  end;
end;

destructor TDLL_Datei.Destroy;
begin
  inherited Destroy;
end;

Das habe ich mal gemacht, weil ich im derzeitigen Projekt 4 oder 5 verschiedene DLL´s habe. Damit konnte ich im Hauptprogramm einfach und schnell die Verfügbarkeit prüfen.

Wie würdet ihr sowas einarbeiten bei euch? Wie gesagt, ich hab derzeit das ganze in einer Pas zu liegen, ist mittlerweile etwas mehr drin und unübersichtlich. Ich weiß auch nicht ob dies in eine Klasse zu packen wirklich "sinnvoll" oder "guter Programmierstil" ist, aber deswegen frage ich ja

Edit: Der Hinweis von jaenicke wurde in #16 wurde eingearbeitet und die Library freigegeben.

[jaenicke]

Zitat von BAMatze:

Wie würdet ihr sowas einarbeiten bei euch? Wie gesagt, ich hab derzeit das ganze in einer Pas zu liegen, ist mittlerweile etwas mehr drin und unübersichtlich. Ich weiß auch nicht ob dies in eine Klasse zu packen wirklich "sinnvoll" oder "guter Programmierstil" ist, aber deswegen frage ich ja

Das in eine Klasse zu legen ist schon gut, wenn du damit ein Objekt (die DLL) kapselst. Aber irgendwie fehlt ein FreeLibrary.

Ich würde das ggf. auf mehrere Units aufteilen, damit die Bibliotheksunits nicht zu unübersichtlich werden. Solange man nicht gerade eine Personal Edition hat, ist das mit der Übersichtlichkeit aber nicht so schnell ein Problem, da man mit den Shortcuts (Strg + Pfeil hoch z.B.) ja schnell zwischen Deklaration und Implementierung wechseln kann und so weiter.

[BAMatze]

Zitat von jaenicke:

Das in eine Klasse zu legen ist schon gut, wenn du damit ein Objekt (die DLL) kapselst. Aber irgendwie fehlt ein FreeLibrary.

Asche auf mein Haupt

@jaenicke also ein Projekt aufmachen und dann so viele Units, wie man verschiedene Funktionen hat und dieses Projekt dann in die neuen Anwendungen einbinden? Oder einfach eine lose Unitsammlung ohne Projekt?

[jaenicke]

Zitat von BAMatze:

Oder einfach eine lose Unitsammlung ohne Projekt?

Ja, ein Projekt kannst du ja nicht einfach einbinden, nur die einzelnen Units.
Die Units sollten dann nach Kategorien sortiert sein was den Inhalt angeht, wenn das ganze größer wird.

// EDIT:
Das mit NTFS Junctions ist nur wichtig, wenn du das Projekt inkl. Quelltext weitergeben willst, weil du dann ja nicht auf Units irgendwo auf der Festplatte referenzieren kannst.

[BAMatze]

Auch wenn die Frage jetzt etwas komisch klingt, wenn ich solche Klassen in extra Units erstelle und sie in anderen Komponenten einbinden will, kann ich das einfach über Unit-.Klausel machen und dann im Erfordert-Bereich die Pas-Datei mit aufführen oder muss ich das dann doch in ein Package packen und über das Package dann die Klasse installieren, damit ich sie am Ende in meiner Komponente einbauen kann?

[jaenicke]

Am einfachsten fügst du die Units einfach dem Projekt hinzu, denn dann kannst du diese in den Units des Projekts einfach via uses verwenden.

requires usw. sind nur für andere Packages, das brauchst du hier gar nicht.

Es sei denn du willst keine NTFS Junctions verwenden und den Quelltext weitergeben, denn dann kannst du die Units ja nicht einfach aus einem Pfad außerhalb deines Projektverzeichnisses einbinden. Dann müsstest du mehr Aufwand betreiben, z.B. was das Eintragen von Pfaden in den Bibliothekspfad angeht.

[Luckie]

Also ich habe auch eine Funktionssammlung in einer Unit. Diese Unit kopiere ich immer in das Projektverzeichnis 8Unterordner) und benutze sie dann. So hab eich keine Probleme, wenn ich das Projhket Opensource veröffentliche, dass da eine Unit fehlen könnte oder so. Benötige ich nur ein, zwei Funktionen, kopiere ich sie mir meist schnell aus der Unit raus.