Organisieren von großen Programmen

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

[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. :stupid:
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 :cry: ... 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:

Zitat von divBy0 (Beitrag 1063687)

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

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1063671)

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? :stupid:

[joachimd]

Zitat:

Zitat von BlueLiquidCell (Beitrag 1063720)

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

[stahli]

Ich hatte kürzlich hier einmal zur Zweckmäßigkeit von Frames nachgefragt und angefangen, das so umzusetzen.
Jeder dieser Frames wird nur einmal im Projekt eingesetzt und soll lediglich einer Trennung von inhaltlichen Bereichen in einzelne Units dienen.

Mich nervt dabei, dass man die Frames dann aber auch in der Mainform hat und daran (un-)absichtlich herumschrauben kann. Grundsätzlich würde ich mir wünschen, dass die IDE Frames optional nur als graues Panel darstellt und nur zur Laufzeit mit Leben füllt.

Die Idee mit eingebunden Formularen klingt aber auch gar nicht schlecht... Werde ich heute Abend mal antesten.
Welche Vorzuge gegenüber Frames kann man denn grundsätzlich nennen?

[rweinzierl]

Vorteile:


Das Formular kann "normal" entwickelt und getestet werden, und bei bedarf auf "im Hauptformular angeklebt" abgeändert werden.

Formulare haben ein Formcreate ... (Frames glaube ich nicht)

Formulare funktionieren seit Delphi 2.0 ziemlich fehlerfrei. ( Zumindest meistens )

...

mfg

Reinhold