Zitat von
Headi:
Ich wäre auch über weitere Tipps zur Übersichtlichkeit sehr dankbar!
Zuerst zu Include-files : besser Finger weg ! Selbst, wenn der Code wiederverwendet werden muß, warum dann mehrmals als Include ein und dasselbe mehrfach speichern und letztenendes die EXE aufblähen ? Wie bereits gesagt : dafür hat man Units. Bei mir gabs bisher eine Ausnahme (zu BP7 Zeiten) : eine
Unit war > 64 kB (damals maximale Editor-Größe !) und es gelang mir nicht recht, diese sinnvoll in Units aufzuspalten. 8) Kurzerhand habe ich die gröte Prozedur aus der
Unit ausgelagert und per Include als 1 Zeile trotzdem drin gehabt. Nachteil : bei Änderungen 2 Quelltexte im Auge behalten. Wegen der Dateigröße Includes zu verwenden ist heutzutage natürlich Schwaschsinn.
Diese
Unit gibt es heute im Prinzip auch noch und mit dem Stil von damals hätte sie wohl 200 kB => wären sicherlich mehr als 4 Includes.
Heute läuft das Ganze dank
OOP völlig anders ab. Eine große
Unit enthält zuerst mal alle Ein/Ausgabe-Routinen. Formatierung und einen Haufen virtueller (vorerst leerer) Prozeduren. Diese ist in der Objektablage gespeichert. Egal welche neue Form gebraucht wird, ich leite sie zuerst mal von dieser ab (also inherited). Der ganze grundlegende Ein/Ausgabekram ist somit bereits ohne 1 Zeile neuen Codes erledigt. Die neue
Unit enthält vorerst lediglich die Formdeklaration, weiß den Rest aber bereits von der Vorgänger-Form. Der neuen Form werden nun die Sachen hinzugefügt, die sie zusätzlich noch braucht. Gut, PageControl : einfach draufpappen. Noch 20 Edits gefällig ? Drauf damit. Vom Vorgänger wissen sie auch bereits, daß sie bei Zahlen rechts- und sonst linksbündig aussehen sollen. Die Schriftgrößen, Farben, Positionen usw. werden auch im
OI möglichst allgemeingültig gehalten. Kann man ja leicht später immer noch abändern.
Was ist nun mit den "leeren" Prozeduren ? Beispiel : speichern in
DB. Sagen wir mal 5 verschiedene PageControls für 5 Tabellen, die nichts miteinander zu tun haben. Die eingegeben Daten sollen im FormClose abgespeichert werden. Das ist im gemeinsamen Vorgänger bereits grob geregelt. Da steht so was drin :
Delphi-Quellcode:
procedure TForm1.WertSpeichern; // virtual deklariert
begin
end;
procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
WertSpeichern;
end;
Richtig : eigentlich nichts ! Das wird nämlich in den Nachfahren erst genauer definiert, weil es dort als override deklariert ist und deshalb erst konkret wird.
Häufig kommt bei solchen Dingen der Einwand, es sei alles so unterschiedlich und deshalb wäre mit
OOP-Mitteln nichts zu machen. Das ist in mind. 85 % der Fälle aber Humbug. Es kann mir keiner erzählen, daß Zahlen,Edits überall anders sein müssen. Also, ich empfehle Dir zuerst mal in der Richtung vorzugehen. Egal, wie der Code momentan aussieht. Es läßt sich mit Sicherheit einiges sinnvoll auslagern. Machst Dus so wie ich, dann kann man das ganze später auch völlig einfach in allen möglichen Projekten wiederverwenden, bzw. durch Änderung an einer einzigen zentralen Stelle für alle Units oder gar Projekte ändern.