Organisieren von großen Programmen

[sx2008]

Es ist sinnvoll, den Sourcecode in zwei Teile zu zerlegen.
* Code, der nur für diese Anwendung benötigt wird
* Code, der so allgemein ist, dass er ohne weiteres auch in einer anderen Anwendung benützt werden kann
Letzteres ist besonders wertvoll, denn einmal programmiert aber mehrfach verwendet spart Zeit.

Ein Beispiel: in einer Anwendung musst du einen String zeichenweise umdrehen.
Der erste Ansatz wäre eine Schleife an Ort und Stelle zu verwenden und die Zeichen im String umzudrehen.
Schrittweise soll das jetzt verbessert werden.
Dir wird klar, dass man den Code nicht einfach so hinklatschen darf, sondern dass man daraus eine Funktion machen muss:

Delphi-Quellcode:

// String zeichenweise umdrehen
function ReverseString(const s:string):string;
...

Bislang hast du die Funktion nur ein einziges Mal gebraucht.
Aber jetzt brauchst du sie ein zweites Mal in einer anderen Unit.
Kein Problem, einfach kopieren.
Dann kommst du drauf, das Copy & Paste Programmierung doch nicht so toll ist(genauer gesagt ist es das Dümmste was man tun kann).
Also nicht kopieren, sondern die Deklaration der Funktion in der Interface-Abschnitt der Unit A schreiben
und dann in Unit B mit Uses einbinden.
Nun brauchst du die Funktion noch ein drittes Mal in Unit C.
Aber wenn du Unit A einbindest bekommst du nicht nur die Funktion ReverseString sondern auch anderes Zeug.
Du entscheidest dich die Funktion in eine eigene Unit namens "Utilities" zu verschieben.
In dieser Unit sammeln sich im Laufe der Zeit nützliche Funktion, Proceduren und Klassen an.
Du teilst die Unit "Utilities" in mehrere Units mit unterschiedlichen Themengebieten (Stringverarbeitung, Datenbankzugriff, Verschlüsselung, ...) auf.

Zum Schluss hast du eine Bibliothek bestehend aus versch. Units, die du auch in anderen Anwendungen einbinden kannst.

[himitsu]

Auslagern in eine DLL soll also besser sein, als ein einfaches Auslagern in verschiedene PAS?
Erhrlich gesagt, ist das sogar umständlicher, da man hier
a) schlechter Debuggen kann (da man im Allgemeinem eintweder die DLL oder die EXE debuggt)
und b) auch noch so Einiges aufpassen muß, wie Shared Memory und die getrennte RTTI, bei Verwendung von Objekten (also 'ne TStringList läßt sich nicht einfach so in beiden Teilen verwenden)

PS: Auch die kompilierten Daten werden nicht kleiner, nur weil man was in eine DLL auslagert.
Im Gegenteil, wenn man dieses nur bei einem Programm macht (also die DLLs nicht mit verschiedenen Programmen nutzt), dann werden es sogar mehr Daten.
Denn die DLL hat ja auch wieder Zusatzinfos und dann sind auch noch viele Daten doppelt (so z.B. die überall genutzten Delphi-Units, einige Resourcen usw.)

[pixfreak]

Moin zusammen,

in meinen C Projekten habe ich genau aus Grund der Vermeidung von DLLs zwecks Auslagerung Gebrauch von statischen Libs gemacht um wiederverwendbaren Code schnell einbinden zu können.

In Delphi schiebe ich wieder zu verwendenen Quelltext, der getestet und für gut befunden wurde, in ein extra "Erweiterungsverzeichnis", welches ich im Suchpfad habe. Dann brauche ich die Unit nur einbinden und alles ist gut. DLLs etc. würde ich nur nutzen, wenn die Funktionen von mehreren Programmen gebraucht werden, oder das Programm in mehreren Instanzen ausgeführt wird. Ansonsten hat man nur Ärger. Und bei der heutigen Hauptspeichergröße ist halt sowieso die Frage was ich will: eine etwas größere exe-Datei oder den Ärger mit DLLs (am besten noch mit inkomplatiblen Schnittstellen...)

Also mein Tip: Alles was funktioniert und nicht mehr angefasst werden soll, ab in eine eigene Unit etc. Ob jetzt als Klassen (vorzuziehen, Stcihwort Vererbung und Ableitung) oder prozedural, aber dann wird das eigentliche Progamm doch wieder übersichtlicher...


Viele Grüße

Pixfreak

[himitsu]

PS: Alles was man als mehrere Prozeduren in einer Unit hat und welches logisch zusammen gehört, das kann man auch Problemlos in eine Klasse auslagern.

Und es wirklich nur Proceduren/Funktionen sind, dann als Klassenmethoden, also mit "class function DerName" deklariert.
So muß man keine Instanz der Klasse erstellen.

Delphi-Quellcode:

Procedure MacheIrgendwasFunktionA(die Parameter);
Procedure MacheIrgendwasFunktionB(die Parameter);
Procedure MacheIrgendwasFunktionC(die Parameter);

Aufruf: MacheIrgendwasFunktionC(übergebene Parameter);

Type TMacheIrgendwas = Class
  Class Procedure FunktionA(die Parameter);
  Class Procedure FunktionB(die Parameter);
  Class Procedure FunktionC(die Parameter);
End;

Aufruf: TMacheIrgendwas.FunktionC(übergebene Parameter);

Über TMacheIrgendwas. hat man dann in der Autovervollständigung dann auch noch eine nette Übersicht der Funktionen.

Und sobald in der Unit auch noch globale Variablen auftauchen, dann gehört sowas sowieso in eine Klasse.
Entweder ebenfalls als Klassenmethoden und mit Klassenvariablen. (als "Class Var" in der Klasse deklariert),
oder eben über ein instanziertes Objekt.
Wobei Letzeres einem erlaubt, die Klasse auch mehrmals im selben Projekt zu verwenden ... Über dar Klassenmethoden/-Variablen wäre nur ein einziges "Objekt" möglich.

[himitsu]

Na gut, wenn man es gleich von Anfang an als Klassen auslegt, dann ist der Mehraufwand nicht unbedingt sooooo groß.

Und wenn man diese Klassenmethoden nicht grade statisch deklariert (mit der Aufrufkonvention "static"), dann gibt es sogar noch einen unsichtbaren internen Parameter (das liebe SELF), welcher bei jedem aufruf soeiner Methode mit übergeben wird.

Ansonsten bringt es im Quellcode auch vorwiegend nur dann mehr Übersicht, wenn man z.B. mehrere ähnliche Funktionsgruppen in einier Unit auf mehrere solcher Klassen verteilt hat.
(Bei einer einzigen Klasse, in der Unit, mag es bestimmt ein winziges Bissl mehr Aufwand sein)

PS: Seit Delphi2006/TDE nutzte ich, bei Sowas, auch gern mal Recordmethoden.
Quasi fast das Selbe wie eine statische Klasse, welche man aber definitiv nicht instanzieren kann. (da das mit den abstracten Klassen ja nicht unbedingt gut funktionierte)

Und wenn es eine Funktion war, welche man zum Manipulieren eines Records nahm, dann ist das auch eine witzige Idee.
Denn früher mußte man den Record an die Funktion übergeben und nun ruft man die Funktion direkt über den Record auf.
(auch hier ist die Autovervollständigung wieder sehr nett, da man sich so die möglichen Funktionen zu diesem Record anzeigen lassen kann.

Ach ja, wer nun mein, daß es jetzt schwerer ist, Aufgrund der fehlenden Vererbung, dieses um Funktionen zu erweitern, der kennt die "Record Helper" noch nicht. ... Ja, das was es für Klassen (Class Helper) gibt, gibt es auch für Records.
(leider nicht für normale Typen ... TGUID hätte ich gern mal nachträglich um die zugehörigen Umwandlungsfunktionen erweitert, wie z.B. GuidToString)


PS: Diese PAS-Dateien von Delphi sind ja grade dazu da, daß man damit Alles schön aufteilen kann.
Nicht so wie in C, wo die ganze Includetechnik eigentlich das gesamte Programm nur in einer rießigen Quelltextdatei virtuellen verwaltet, wo eigentlich nichts wirklich voneinander getrennt ist (selbst wenn es in verschiedenen C- und H-Dateien drinsteht).

[divBy0]

Was ist denn mit Packages und BPL?

[himitsu]

Zitat von divBy0:

Was ist denn mit Packages und BPL?

BPL ist auch "nur" eine DLL (mit speziellen Delphizusatzfeatures).
Also hier gilt das Selbe, wie bei den DLLs.
Wenn man das für nur ein Projekt macht, bringt es wohl nicht wirklich Vorteile.
Und bei Verwendung in mehreren Projekten muß man hier zusätzlich aufpassen.

PS: Die BPL muß mit dem selben Delphi-Compiler und der selben RTL/VCL-Version kompiliert sein, wie die EXE, welche sie verwenden will,
da ja die selben RTTI-Informationen verwendet werden müssen.
Dagegen ist eine "normale" DLL natürlich unabhängiger.

Wenn du also 2 Programme hast, welche die "gleiche" BPL nutzen will, aber das eine Programm noch in D2006 geschrieben ist, aber das andere Programm schon mit D2007, dann müssen auf dem Zielsystem irgendwie die BPLs für beide Delphiversionen installiert/vorhanden sein.
Und wenn das nun die einzigen Programme sind, welche diese BPLs nutzen, dann ist doch der Aufwand damit größer?

[s.h.a.r.k]

Bzgl. den DLLs kann man eben argumentieren, dass man bestimmte Funktionen eben in mehreren Programmen verwenden will, somit kann man das ja in eine DLL packen -- holt sich dabei aber auch einige Probleme mit ins Boot. Ich persönlich verzichte all zu gerne drauf.

@himitsu: Ich habe das auch mit diesen tollen statischen Klassenmethoden, bin aber aufgrund des Mehraufwandes nicht wirklich begeister von dieser Lösung. 100% OOP gibts eh nicht imho.

[Assarbad]

Zitat von himitsu:

Erhrlich gesagt, ist das sogar umständlicher, da man hier
a) schlechter Debuggen kann (da man im Allgemeinem eintweder die DLL oder die EXE debuggt)

Bedingtes Kompilieren? Anyone?

[nachti1505]

Zitat von sx2008:

Du teilst die Unit "Utilities" in mehrere Units mit unterschiedlichen Themengebieten (Stringverarbeitung, Datenbankzugriff, Verschlüsselung, ...) auf.
Zum Schluss hast du eine Bibliothek bestehend aus versch. Units, die du auch in anderen Anwendungen einbinden kannst.

Ich nehme an, diese Unit binde ich dann nur per uses ein, oder? Was wäre denn der Unterschied zum Hinzufügen zum Projekt? Bzw. was ist generell der Unterschied zwischen uses und einbinden?