Organisieren von großen Programmen

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

[BlueLiquidCell]

Hey
Bei den Forms ist halt das Problem das ich die Variablen dann nur in der Form(auf der Tab seite) benutzen kann, bräuchte sie aber manchmal auch global.

Das mit den Klassen hört sich doch nach relativ viel aufwand an, vorallem weil ichs nicht von anfang an eingeplant hab ist aber wohl ne relativ gute Lösung wenn man noch länger an dem Programm arbeiten will. Muss ich mir aber erstmal genau angucken weil ich damit noch nicht wirklich was gemacht hab.

Vorteil von dlls gegenüber auslagern in ner pas ist doch dass das Hauptprogramm kleiner wird und er die dll nur läd wenn ers braucht. Oder seh ich das falsch?
StaticLibrary wär natürlich auch ne idee.
Bezüglich des debuggen hab ichs immer so gemacht das ich zunächst eine Funktion im Hauptprogramm ausprobiert hab und nachdem alles lief die funktion in die dll gepackt hab. Dann entfällt nachträgliches debuggen meistens.

Merci, für die vielen Antworten und anregungen
Christoph

[joachimd]

Zitat von BlueLiquidCell:

Bei den Forms ist halt das Problem das ich die Variablen dann nur in der Form(auf der Tab seite) benutzen kann, bräuchte sie aber manchmal auch global.

Dann gib diese als Property in deine Form-Klasse und lese sie auch so wieder zurück. Vorteil davon: Du kannst richtig schön Formular für formular entwickeln und unabhängig(!) voneinander testen. Am Besten noch von einem gemeinsamen Vorfahren abgeleitet, damit du einzelne Methoden/Properties schonmal voraussetzen kannst (ohne tausender TypeCasts).

[rweinzierl]

Hallo

Mein persönlicher Ansatz bei einem Formular mit vielen Pagecontrols den Code in einzelne Formulare zu trennen und diese dann ähnlich wie Frames auf dem Hauptformular zusammenzufassen.

Delphi-Quellcode:

myFrm:= TmyFrm.Create(Application);
myFrm.Position := poDefault;
myFrm.Parent := EinesDerTabsheets;
myFrm.BorderStyle := bsNone;
myFrm.Left := 0;
myFrm.top := 0;
frmVentilatorECZuluft.show;

Natürlich trennt man trotzdem Code und Darstellung, aber so habe ich nicht alles in einem Monster Formular und trotzdem für den Anwender alles schön kompakt.

mfg

Reinhold