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

[holliesoft]

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