Organisieren von großen Programmen

[BlueLiquidCell]

Hey Guys
Habe mittlerweile ein ziemlich großes Programm geschrieben.
(ca. 20000 Zeilen)
Leider ist es mit der Übersicht bei der größe ziemlich schwierig.

Das Programm hat mehrere TabFenster. Würde gerne den Code der zu jedem Fenster gehört zusammen haben.

Kann man den jeweiligen Code irgendwie in ne externe unit schreiben?
Geht dabei um relativ viele Buttons bzw Panels auf die man klicken kann.

Klar könnte dann für jeden knopf ne function schreiben die ich aufrufe. Dann muss ich aber viel zu viele Variablen immer übergegeben etc... Gehts auch einfacher?

Hab übrigens schon da wos ging die functions in ne dll gepackt. Aber bei onClick procedures macht das keinen sinn oder?

Hoffe ihr habt nen paar ideen. Danke schonmal!

[Luckie]

Zitat von BlueLiquidCell:

Hab übrigens schon da wos ging die functions in ne dll gepackt.

Und wie trägt das zur Übersicht im Quellcode bei? Trenne Oberfläche von den Daten und der Funktionalität.

Zitat:

Klar könnte dann für jeden knopf ne function schreiben die ich aufrufe.

Das wäre schon mal ein Ansatz. Und wenn du dann noch sauber alles in Klassen verpackst, sollt es mit der Übersicht besser werden.

[BlueLiquidCell]

Hey
Danke für die schneller Antwort!

Naja das Programm hat noch ein Interface zu einem anderen Programm dazu müssen viele Daten in einem bestimmten format (welches ich nicht benutzen will) konvertiert werden und dann in das interface geschrieben werden. Damit der ganze code nicht im Hauptprogramm ist hab ichs in ne dll gepackt. Insofern trägts schon zur Übersicht bei.

Ok das mit den Klassen ist ne idee aber muss ich dann nicht auch alle benötigten Variablen übergeben? Sorry hab noch nicht so viel mit Klassen gemacht.

Schöne Grüße
Christoph

[Bummi]

Ich weiß nicht ob meine Vorschlag für Dich brauchbar oder praktikabel ist.
Du könntest statt Tabs einzelne Forms erstellen, welche Du nach dem erstellen Deines Mainform per ManualDockDrop in ein leeres Tabscheet integrierst.
Du kannst dann überallhin direkt durchgreifen und hast in dem Forms den zugehörigen Code.

[alzaimar]

Ich dachte, dazu dienen Frames...

[Bummi]

@alzaimar

das ist eine persönliche Angelegenheit zwischen den Frames und mit.
Ich bin vor einigen Jahren von den damals fehlerhaft funktionierenden Frames auf Forms umgestiegen und war damit so zufrieden, daß ich nie wieder einen Grund sah zu wechseln.

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