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

[BAMatze]

Hallo an alle DPler,

Hab hier mal eine Frage an die etwas versierteren Programmierer. Und zwar habe ich ein paar hilfreiche Klassen geschrieben (keine Komponenten), die mir ein paar Funktionen zur Verfügung stellen, die ich ab und zu brauche (Ein kurzes Beispiel ist z.B. eine Klasse, die eine Datei auf vorhandensein prüft und wenn vorhanden das Handle zurück gibt).
Wie verwaltet ihr solche Quellcode, die an sich nicht in Komponenten umgewandelt werden aber trotzdem sinnvoll sind? Bisher kopiere ich meistens den Quellcode in die Pas-Datei, was nicht sinnvoll ist. Sicherlich wären unabhängige Pas-Dateien sinvoller, aber wie stellt man die so zusammen, dass man auch in einem Jahr noch weiß, was wo drin ist, welche Funktionen da drin stecken, ... .

Würe mich über Anregungen in der Organisation sehr freuen,

Vielen Dank
BAMatze

[Tyrael Y.]

Zitat:

Zitat von BAMatze

...aber wie stellt man die so zusammen, dass man auch in einem Jahr noch weiß, was wo drin ist, welche Funktionen da drin stecken, ... .

Indem ich den Quelldateien vernünftige - alle Unklarheiten beseitigende und genau die Funktionalitäten beschreibende - Namen vergebe.

...und wenn ich in einem Monat bemerke, daß der Name doch nicht ganz vernünftig war, ändere ich es wieder.


Edit: Jede Klasse in eine Datei ist für mich Pflicht.

[MisterNiceGuy]

Bastel dir eine CodeLibrary in der du alle nötigen Funktionen ablegst und dann bei Bedarf rauskopierst ;)

Prinzipiell ist nichts gegen Klassen einzuwenden, allerdings zweckentfremdest du das Klassenprinzip hier ein bisschen. Schließlich fällt ja in deinem Falle die Benutzung von Membervariablen (Variablen in der Klasse) komplett weg. Wenn du später mal hoch effizient programmieren willst (Echtzeitanwendungen/Spieleentwickung), dann solltest du auf übermäßigen Klassengebrauch/Verarbung so gut es geht verzichten, da Sprünge zwischen Klassen immer Overhead produzieren (z.B. durch Parameterübergaben durch den Stack etc). Deswegen -> Codelib :stupid:

[holliesoft]

Zitat:

Zitat von BAMatze

Bisher kopiere ich meistens den Quellcode in die Pas-Datei, was nicht sinnvoll ist. Sicherlich wären unabhängige Pas-Dateien sinvoller, aber wie stellt man die so zusammen, dass man auch in einem Jahr noch weiß, was wo drin ist, welche Funktionen da drin stecken, ... .

Ich selbst verwende für meine eigenen, immer wieder verwendeten Codeschnipsel (z.B. Konvertierung des Datums in das Format YYY-MM-DD, Auslesen der Versions-Nummer, Prüfung ob ein Datenträger im Wechsellaufwerk vorhanden ist) eine einzige PAS-Datei, die ich dann in die Projekte einbinde.
Welche Funktionen da drinnen sind, habe ich weitgehend im Kopf. Aber es ist vielleicht auch nicht verkehrt, sich eine Dokumentation zu schreiben, in der man seine Klassen und Funktionssammlungen nach Themengebieten ordnet. So etwas hatte ich vor 2 Jahren mal angefangen, aber leider nicht gepflegt (zu wenig Zeit ;-).

Gruß
Patrick

[jaenicke]

Ich verwende recht intensiv Quelltexte oder ganze Projekte (z.B. eins zur Verwaltung von Einstellungen) in anderen Projekten wieder. Dafür nutze ich NTFS Junctions, so dass ich Bibliotheksordner oder Projektordner direkt in die jeweiligen Projekte eingeblendet habe. Wenn ich dann etwas an der Bibliothek verbessere, kommt das auch allen Projekten zugute.

Zudem kann ich das Projekt inkl. Quelltext direkt so ausliefern ohne die Pfade ändern zu müssen, denn für das Projekt liegen die Units ja in einem Unterordner des Projekts und werden bei der automatischen Paketerstellung auch mit erfasst. Die Pfade stimmen dann direkt. Insofern nehmen NTFS Junctions an der Stelle sehr viel Arbeit ab, man muss dafür aber eine klare Struktur in den Projekten haben.

Voraussetzung ist natürlich eine gute Dokumentation, so dass man weiß was wo verwendet wird und welche Auswirkungen eine Änderung dementsprechend auf andere Projekte haben kann.

[Luckie]

Zitat:

Zitat von MisterNiceGuy

Wenn du später mal hoch effizient programmieren willst (Echtzeitanwendungen/Spieleentwickung), dann solltest du auf übermäßigen Klassengebrauch/Verarbung so gut es geht verzichten, da Sprünge zwischen Klassen immer Overhead produzieren (z.B. durch Parameterübergaben durch den Stack etc).

Ersteres ist für Delphi unerheblich, da Windows kein Echtzeitbetriebssystem ist und zweiteres wage ich zu bezweifeln, da der produzierte Overhead auf heutigen Systemen nicht weiter ins Gewicht fallen dürfte.

[mschaefer]

Lege solche Klassen in ein Package. Auch wenn es keine Komponenten enthält. Einerseits kann ich dieses Package dann auch in Packages für Komponenten verwenden und andererseits habe ich diese Klassen nicht immer im jeweiligen Projekt mitzuverwalten. Für die Packages habe ich dann noch einzelne Verzeichnisse. Nur DCU und BPL Dateien kommen dann in gemeinsame Packageausgabeverzeichnisse.

Grüße // Martin

[Phoenix]

Zitat:

Zitat von jaenicke

Voraussetzung ist natürlich eine gute Dokumentation, so dass man weiß was wo verwendet wird und welche Auswirkungen eine Änderung dementsprechend auf andere Projekte haben kann.

Hier empfehle ich Pasdoc. Du dokumentierst Deine Funktionen und alle Parameter etc. direkt im Source und generierst die Doku (z.B. als HTML-Datei) automatisch. Finde ich klasse.

[BAMatze]

Zitat:

Zitat von jaenicke

Insofern nehmen NTFS Junctions an der Stelle sehr viel Arbeit ab, man muss dafür aber eine klare Struktur in den Projekten haben.

@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?

@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.

BAMatze

[Tyrael Y.]

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

Wenn ja, dann schlage ich dir mal Klassenfunktionen vor.
Alle Funktionen und Prozeduren, die einen bestimmten Zweck verfolgen fasst du damit in
einen Namensraum zusammen.

Delphi-Quellcode:

type
  TStringManipulator = class
  public
    class function Manipulate(AString: String): string;
   ...

Du brauchst dann auch nicht die Klassen zu instanzieren und rufts die Funktionen über den Namensraum auf.

Delphi-Quellcode:

  ... 
  newString := TStringManipulator.Manipulate(myString);
  ...

Ich benutze gerne solche Zusammenfassungen über Klassen mit reinen Klassenfunktionen.

[jaenicke]

Zitat:

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:

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:

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:

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 :D

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

[jaenicke]

Zitat:

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 :D

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:

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. ;-)

:wall: Asche auf mein Haupt :oops:

@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:

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.

[Tyrael Y.]

Hm...wie schon erwähnt benutze ich überhaupt keine Units mit reinen Funktionen mehr.

Der Vorteil von Klassen-Methoden ist, dass du die Funktionen in solchen Klassen sehr gut Gruppieren kannst.

Ich finde einen Karteikasten mit sehr vielen Karteikarten viel schöner
als ein Rolle Papier aus einem Drucker, daß immer weiter beschrieben wird.

[stoxx]

Klassen = Komplexität verbergen. (Zitat nach Hagen, das war der beste Ratschlag meines Lebens :-)


Wenn ich etwas programmiere und ich weiß, dass ich diese Aufgabenstellung noch einmal benötigen könnte, dann möchte ich diese das nächste mal mit 3 Zeilen Code erledigt haben (Programmieren nach dem Konzept der "Faulheit" ... und gar nicht mehr wissen, was intern geschickt.

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

[BAMatze]

Zitat:

Zitat von stoxx

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Ja sowas möchte ich mir ja auch jetzt langsam mal anlegen. Finde die Möglichkeit etwas in Klassen zu packen, um dann bestimmte Vorgänge intern regeln zu können sehr schön. Für mich stehen da aber wie man merkt noch einige Fragen offen, die dann bei der Umsetzung eines Programms wichtig sind. Möchte ja nicht heute eine schöne und umfangreiche Arbeit machen, um später festzustellen, Mensch schön dass ich das alles fertig gemacht hab, aber verwenden kann ich es nicht, weil irgendein Fehler im vorherigen Denken anlag(z.B. ich leg jetzt nur Units an und nachher kann ich sie nicht in eine Komponente einbinden).

MfG Bamatze

[Namenloser]

Zitat:

Zitat von stoxx

Klassen = Komplexität verbergen. (Zitat nach Hagen, das war der beste Ratschlag meines Lebens :-)


Wenn ich etwas programmiere und ich weiß, dass ich diese Aufgabenstellung noch einmal benötigen könnte, dann möchte ich diese das nächste mal mit 3 Zeilen Code erledigt haben (Programmieren nach dem Konzept der "Faulheit" ... und gar nicht mehr wissen, was intern geschickt.

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Da gebe ich dir recht (ich programmiere selbst sehr objektorientiert), aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit ist, oder intuitiver oder praktischer zu benutzen, weil verschachtelbar oder oder oder...

Ich persönlich binde eigene "Bibliotheken" eigentlich genau so ein, wie fremde. Ich kopiere sie aus dem Entwicklungsverzeichnis in mein Lib-Verzeichnis (ein eigenes, nicht das von Delphi, weil mir das sonst zu unübersichtlich wäre) und binde dann die Unit ein. Dieses Verzeichnis ist teilweise wieder in Unterverzeichnisse gegliedert, um die Übersicht zu behalten. Das hat leider den Nachteil, dass ich z.B. bei einer Neuinstallation mordmäßig viel zeug in die Bibliothekspfade eintragen muss. Das mit den Packages finde ich sehr clever, bin bisher nie darauf gekommen, die so zu nutzen, werde das aber glaube ich in Zukunft auch so machen.

[DP-Maintenance]

Dieses Thema wurde von "Phoenix" von "Programmieren allgemein" nach "Sonstige Fragen zu Delphi" verschoben.
Generell gehts schon um Delphi, also verschieb ich das mal dahin.

[stoxx]

Zitat:

Da gebe ich dir recht (ich programmiere selbst sehr objektorientiert), aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit ist, oder intuitiver oder praktischer zu benutzen, weil verschachtelbar oder oder oder...

nur bedingt .. zu jeder function gehören auch Daten. Wenn es nicht gerade die Funktion "now" ist, die nur die aktuelle Uhrzeit zurückgibt.
Und wenn jemand der eigenen persönlichen Einbildung unterliegt, ein Funktionsaufruf in einer Klasse wäre soviel langsamer als ein direkter Funktionsaufruf, dem seien die neuen Records ans Herz gelegt.

ob man nun Data.calc, oder function Calc(const aData: TMyData); aufruft ..
ist letztendlich gleich und wird vom Compiler in gleicher Weise umgesetzt ...

Zitat:

aber es gibt auch Fälle, wo eine Funktion wesentlich weniger Tipparbeit

als 10 Finger-tipper stören immer die vielen Klammern ... so ein Punkt bei data.calc ist viel schneller aufgerufen :-)

[Hansa]

Zitat:

Zitat von stoxx

Wenn man so von "unten" anfängt, ensteht nach und nach ein tolles eigenes Klassenframework, mit dem Du super arbeiten kannst ..

Das gilt aber auch für Forms oder Projekte. Hier fangen vermutlich 95 % mit einem neuen leeren Formular an. Dann wird angepasst. Die Schriften/Größen, die Farben, Captions usw. Im Prinzip wird immer wieder ein und dassselbe neu gemacht. Für jemand, der nur ein Formular in einem einzigen Projekt hat, der kann das auch so machen. Alle anderen sind durch diese Vorgehensweise aber schlecht beraten. Bei mir ist es z.B. immer so, dass eine Form mit esc geschlossen werden kann, oder es mit Enter in einem Grid weiter geht. Das ist den ISO-Normen geschuldet. Weder Alt-F4 noch Tab nach Win-"Standard" sind ISO-konform. Statt nun tatsächlich mit neuem leeren Formular anzufangen nehme mich mir zumindest eines aus der Objektablage, was dieses Minimum schon kann. Im Laufe der Zeit hat sich so schon eine beachtliche Anzahl immer ausgefeilterer Formulare angesammelt. Ich brauche mir für einen gewissen Zweck nur das richtige auszusuchen und 80 % der Arbeit ist bereits erledigt ! Im Endeffekt kommt dann dabei heraus, dass äußerst komplexe Formulare tatsächlich nur 100 Zeilen haben. :P

[MisterNiceGuy]

Zitat:

...zweiteres wage ich zu bezweifeln, da der produzierte Overhead auf heutigen Systemen nicht weiter ins Gewicht fallen dürfte

@Luckie: Der ins gewichtfallende Overhead ist der der moderne Spiele auf deinem Rechner ruckeln lässt ;)