Ich habe mal eine Frage an die Runde hier:

Wie baut ihr Eure Projekte auf?
a) Eine Hauptunit und bestenfalls irgenwelche Tool-Units (strikt getrennte Einheiten) oder
b) eine Hauptunit, mehrere Unterunits (nicht strikt davon getrennt) und Tool-Units oder
????


Anmerkungen vorweg:
Bei größeren Projekten gehe ich so vor: Ich teile das Hauptprogramm (die Hauptunit) in mehrere thematische Unterunits auf. Da diese eng mit der Hauptunit verbunden sind, komme ich nicht umhin, dann diese in dem Implementation-Teil der Hauptunit aufzuführen, da es sonst Kreuzverweise gibt. Genauso erscheint bei den Unterunits die Hauptunit im Uses des Implementation-Teils. Ich habe schon allein wegen des Programmumfangs dies so gewählt. Ansonsten hätte ich eine Unit mit mindestens 200.000 Zeilen. Allerdings habe ich dadurch ca. 20 Unterunits.

Bin auf Eure Meldungen gespannt.

Bis dann.

Hallo,

Tranx hat folgendes geschrieben :

Ich habe mal eine Frage an die Runde hier:

Gut, dass Du dir darüber Gedanken machst!

Tranx hat folgendes geschrieben :

Da diese eng mit der Hauptunit verbunden sind,

Fehler. Nichts darf mit niemand eng verbunden sein. Wenn dann sollte eine Verbinung nur in eine Richtung notwendig sein, z.B. dass die Hauptunit die anderen Units kennt um die Formulare aufzurufen. Wobei so etwas auch in eine eigene unit ausgelagert werden kann, die die Navigationssteuerung übernimmt. Diesen Punkt solltest Du dringend überdenken.

Tranx hat folgendes geschrieben :

Ansonsten hätte ich eine Unit mit mindestens 200.000 Zeilen.

das geht gar nicht

Tranx hat folgendes geschrieben :

Allerdings habe ich dadurch ca. 20 Unterunits.

mein aktuelles Projekt (privat) hat ca. 100 Formulare, dazu noch div. Units mit Klassendeklarationen (i.d.R. eine Klasse pro Unit). Mein Projekt auf der Arbeit hat ca. 500 Formulare und eine entsprechende Menge an zusätzlichen Units.


Grüße

Über das Thema werden sehr sehr dicke Bücher geschrieben.

Die Klassen sollten möglichst eine Aufgabe haben. Andere Aufgabe, andere Klasse.
Ich mache in der Regel eine Klasse pro Unit. Wobei es da auch Ausnahmen gibt.

Die Anzahl der Units ist nicht schlimm. Ich hab grade mal nach *.dfm suchen lassen: also knapp 200 Formulare/Datenmodule. Dazu kommen 400 *.pas-Dateien. Und ja, ich finde in der Regel das was ich suche in meinem Quellcode auf Anhieb. Das liegt vor allem daran, dass ich Dinge nach einem bestimmten Muster benenne und dieses Muster auch einhalte. Und wenn ich feststelle, dass ich mein Muster versehentlich verletzt habe, dann mache ich mir die Mühe und ändere diesen Umstand.

Wie gesagt, das Thema füllt einige Regalmeter.

Bei mir sind die "Unterunits" zumeist ohne Klassendefinition. Eigentlich nur eine Code-Auslagerung der Hauptunit. Warum ich das mache? Weil ich dann bestimmte Prozeduren einfacher bearbeiten kann. Zum Beispiel habe ich Keydown-Prozeduren in einer Key-Unit. Aber ich sehe schon, dass ich wohl total falsch arbeite. Das war dadurch einfach - für mich - besser aufgeräumt. Denn die Keydown-Prozeduren z.B. mussten eine Menge Tastaturabfragen in Abhängigkeit vom Feldinhalt und vom Feld, von dem Status des Datensatzes, von Feldinhalten anderer Felder bearbeiten. Es handelt sich hier um eine Auftragsbearbeitungs- und Abrechnungssoftware und im anderen Fall um eine Messaufnahme- und Datenbearbeitungssoftware incl. Berichtserstellung... Wenn ich das alles in eine Unit schreibe, dann werden das sicher 100.000 Codezeilen. Und die Unterunits benötige ich überhaupt nicht in anderen Programmen, da sie bloß auf diese Anwendung zugeschnitten sind, daher macht es wenig Sinn, die wirklich von den Hauptunits zu trennen.

Man kann auch Formulare und Controls vererben.

Ich habe auch so einige Sachen in meiner Software, die auf spezielle Tastendrücke reagieren. So kann man z.B. Grids anpassen, wenn man eine bestimmte Taste drückt (z.B. auswählen welche Spalte man sehen möchte, etc.). Da diese Funktion in allen Grids die selbe ist, habe ich mir ein eigenes Grid abgeleitet und dort diese Funktion implementiert.

In den Formularen möchten meine User mit Enter statt Tab ins nächste Feld springen (ich finde das doof, aber das sei mal dahin gestellt). Dafür habe ich ein Basisformular, das diese Funktion implementiert. Von diesem Basisformular erben alle meine Formulare in der Anwendung.

Mit diesen Ableitungen kann ich mich in den konkreten Formularen auf deren konkrete Funktion konzentrieren und muss mich nicht mit den Grundlegenden Funktionen rumärgern.

In meinen Projekten sind die Hauptformula-Units gewöhnlich sehr aufgeräumt. Das gilt mit ein paar Abstrichen aber auch für alle anderen Forumular-Units. Im den Ereignisbehandlungen finden sich lediglich Verweise auf private Methdoden oder auf eingeundene Klassen-Units. So weit wie möglich werden Klassen-Units verwendet, die spezielle Aufgabenbereiche abdecken. So habe ich z.B. bei Datenbankanwendungen stets eine Klasse TDatBankEdit, die nahezu alle Datenbank-Aktionen ausführt. Manchmal (und zunehmend seltener) habe ich auch eine Non-Class-Unit (meist Allg.pas genannt), die in ihrem Implementation-Teil all jene Formular-Units aufführt, in denen z.B. Statusbars oder Labels von Ereignissen im Datenmodul verändert werden müssen oder die Globale Variablen bereithalten, auf die einige der Formular-Units angewiesen sind. In dieser Allg.pas finden sich dann die entsprechenden Methoden wie z.B. StatbarMainAktuell, um die Statusbar der Hauptform zu aktualisieren, wenn sich z.B. der Datensatz-Zeiger einer Tabelle ändert (AfterScroll). Ansonsten gibt es bei mir dann noch die Klasse in der Utils-Unit, die im selben öffentlichen Benutzerordern liegt wie die installierten Zusatzkomponenten, z.B. "C:\Users\Public\Documents\RAD Studio\6.0\Utils.pas". Dahinein befördere ich Methoden, die ich voraussichtlich in anderen Projekten wiederverwende, wie z.B. den Aufruf einer externen Anwendung anhand eines Dateinamens oder den Broser anhand einer URL und weitere nützliche Methoden eben. Damit fahre ich nun schon seit Jahren gut. Allerdings habe ich auch keine Mammut-Projekte am Laufen, das größte hat gerade mal um die 150.000 Zeilen ...

Hallo Alle,

folgende Gesichtpunkte fehlen m. E. in der bisherigen Diskussion:

Pro Klasse eine Unit ist schon eine gute Faustformel. Wenn mehrere Klassen in einer Unit sind, dann sollten die so eng verwandt sein, dass eine einzelne Nutzung praktisch sinnlos ist. Die Wieder-/Mehrfachverwendbarkeit von Code ist ja ein Grund für den Erfolg der objekt-orientierten Sprachen. Da ist es wenig sinnvoll, einzeln nutzbare Klassen in einer Unit unterzubringen.

Wenn die Klassenstruktur gut gewählt ist (nicht ganz einfach), dann ist das auch mit den Units ein Selbstgänger und Kreuzbezüge sollte es nicht geben. Wenn in einer Hauptunit eine FUNCTION liegen muss, die in einer Klasse einer Unterunit aufgerufen werden soll, dann definiere ich den FUNCTION-Header in der Unterunit und übergebe dann die FUNCTION zur Laufzeit als Parameter, als Property o.ä.. (Ist ja nur ein Pointer auf dem Stack, ein mov-Befehl o.ä., geht also schnell.) Damit ist die Wiederverwendbarkeit der Unterunit gegeben.

Bei reinen Proceduren wie z. B. in den üblichen Mathematik-Libraries kann es ja kaum einen Rückbezug geben. Da ist eine thematische Aufteilung sinnvoll nach dem Motto "Wer addieren will, der will wohl auch subtrahieren, multiplizieren...."

Handlichkeit: Mehr als einige 100 Zeilen sind mir im Editor unhandlich.

Sicherheit: Man arbeitet ja meist aktuell nur an einem begrenzten Teil des Codes. Wenn dann der restliche Code in anderen Units liegt, dann ist man sicher, dass nur in dem aktuellen Bereich etwas geändert werden konnte. Zwar hatte ich den letzten richtigen Compiler-Bug vor mehr als 10 Jahren, aber trotzdem, im Prinzip ist es bei wichtigen Projekten ein Vorteil, wenn nicht auszuschließende Compilernebenwirkungen auf einen engen Bereich begrenzt werden können. (Es muss ja nur die geänderte Unit übersetzt werden.)

Gruß GuaAck

Hallo,

Tranx hat folgendes geschrieben :

Aber ich sehe schon, dass ich wohl total falsch arbeite.

Das sehe ich nicht so.
Eine wichtige Frage ist wohl zuerst, ob man beruflich oder aus Spaß privat seine Programme erstellt.
Ist es meine Arbeit, so habe ich mich ohnehin dem Team anzupassen und muss garantieren, dass auch "nach mir" andere den Quelltext bearbeiten können. Dann geht es ohne klare Trennung in einzelne Klassen-Units nicht.

Ist das Programmieren mein Hobby, so muss und kann ich meine eigene, effektive Methode finden.
Da ich niemals richtig(!) den ganzen Spaß mit den Klassen gelernt habe und mich nur schwer von der alten Pascalprogrammierung trennen kann, ist für mich die Konstruktion von Units, die bestimmte Prozeduren enthalten, immer noch das Beste.

Z.B. enthält eine Unit Prozeduren zum Drucken von irgendwelchen Objekten. Eine Prozedur druckt eine Paintbox, die andere ein Image, die nächste einen Text, usw.
Andere Units kümmern sich um die Ein- und Ausgabe von Zahlen, Strings, um das Laden und Speichern von Daten ... Eine Unit enthält eine Funktion, die nach der Übergabe eines Funktionsstrings diesen analytisch differenziert, eine andere deren Funktionswert berechnet. usw. usf.

Insgesamt fahre ich damit sehr gut. Ich finde schnell die entsprechenden Prozeduren und es gibt auch keine Querverbindungen zwischen den Units. Und fast alles ohne selbstkonstruierte Klassen; mit Ausnahme derer, die zu einem Formular gehören.

Natürlich würde kaum jemand meine Quelltexte nachvollziehen können, aber sie sind ja ohnehin für mich, und als Hobbyprogrammierer ist dies meine, beste Vorgehensweise. Immerhin hat mein Hauptprojekt im Moment mehr als 350000 Zeilen in rund 500 Units.

Ich denke, jeder muss selbst seine Methode finden. Ist es mein Job, sind die Regeln klar durch die jeweilige Firma vorgegeben.

Beste Grüße
Mathematiker

Mathematiker hat folgendes geschrieben :

Hallo, Tranx hat folgendes geschrieben : Aber ich sehe schon, dass ich wohl total falsch arbeite. Das sehe ich nicht so.

doch ist so... Und du arbeitest auch nicht so. Soll ich dir das beweisen?

Mathematiker hat folgendes geschrieben :

... und es gibt auch keine Querverbindungen zwischen den Units.

DAS ist das entscheidende. In einem Buch stand mal: Gute prozedurale Programmierung ist besser als schlechte OOP. Wenn Du deine Units mit deinen Prozeduren so aufbaust, dass diese "beliebig" nutzbar sind - warum nicht.

Dass das Mainform andere Units einbindet ist kein Problem. Aber es darf einfach nicht sein, dass in die Units das Mainform eingebunden wird. Dann läuft was falsch.

Lemmy hat folgendes geschrieben :

Dass das Mainform andere Units einbindet ist kein Problem. Aber es darf einfach nicht sein, dass in die Units das Mainform eingebunden wird. Dann läuft was falsch.

Also - wenn ich das so sehe - arbeite ich falsch. Liegt mit Sicherheit daran, dass ich mir die Sache selber vor 10 Jahren habe aneignen müssen. Vorher hatte ich mir OP nichts am Hut. In Turbo-Pascal war das für mich was wie böhmische Dörfer.

Nun frage ich mich aber? Wenn ich nun die Hauptunit nicht einbinden darf, aber eine Key-Unit nur die Tastatur-Ereignisse aufnimmt, die das Hauptformular bekommt, und dies bearbeitet, dann habe ich ja gar keine Chance, ohne Einbindung der Hauptunit die Prozeduren in verschiedene Units aufzusplitten.

Benutzung von Application.Mainform bringt nichts, weil dort die Objekte (weil TForm) des abgeleiteten Hauptformulars nicht existieren

abgeleitete Klassen des Hauptformulars in den Unterunits zu implementieren und auf diese dann zuzugreifen, geht auch nicht, weil ich dann die Hauptunit ebenfalls einbinden müsste.

Tja, wie ich es drehe und wende, meine Vorgehensweise ist falsch. Basta. Jetzt kann ich nur überlegen, ob ich das Ganze wieder rückgängig mache, oder nicht. Das Ergebnis wird dann sein, dass ich statt jetzt 25 Units, nur noch 5-6 habe, dafür aber wohl eine Aufgeblähte Hauptunit. Denn alle anderen Units habe ich strikt getrennt, weil ich sie in mehreren Projekten nutze. Nur frage ich mich, was das die Übersichtlichkeit verbessert. Wie gesagt, ich habe die Trennung wegen der Größe der Hauptunit vorgenommen. Und da ich eh neben zwei größeren Projekten keine weiteren nennenswerten Projekte schreibe, war es mir einfach nur wichtig, dass ich selber schnell bestimmte Routinen finde.

Tja, so ist das, wenn man als totaler Laie programmiert. Kommt nur Müll raus. Danke für Eure Hinweise.

Tranx hat folgendes geschrieben :

Nun frage ich mich aber? Wenn ich nun die Hauptunit nicht einbinden darf, aber eine Key-Unit nur die Tastatur-Ereignisse aufnimmt, die das Hauptformular bekommt, und dies bearbeitet, dann habe ich ja gar keine Chance, ohne Einbindung der Hauptunit die Prozeduren in verschiedene Units aufzusplitten.

Doch, so ist das vollkommen normal. Aber ich sehe keinen Grund die Unit des Hauptformulars einzubinden. Aus den Handlingklassen kann man z.B. Events auslösen, die das Hauptformular dann behandelt. Oder man benutzt Interfaces, was das ganze oft einfacher macht.

Konkret kann man dazu aber ohne ein konkretes Beispiel nicht so viel sagen (außer ein eigenes Beispiel zu machen, das kann ich grad zeitlich nicht ).

jaenicke hat folgendes geschrieben :

Aus den Handlingklassen kann man z.B. Events auslösen, die das Hauptformular dann behandelt. Oder man benutzt Interfaces, was das ganze oft einfacher macht.

Wie soll dann z.B. das Event AfterScroll, das im Datenmodul stattfindet, einen Eintrag z.B. in FormMain.StatusBar.Panels[0].Text ändern können, wenn ich dort z.B. den aktuellen Artikel-Index anzeigen möchte. Etwa stattdessen auf Änderung einer Anzeige-Komponente wie z.B. FormMain.TDBEdit_Artikel achten? Das Datenmodul kennt FormMain bzw. UnitMain ja nicht ...

Das Hauptformular kennt doch das Datenmodul.
Also kannst Du im DM ein Event deklarieren:



Im Datenmodul kannst Du dann das Event an passender Stelle aufrufen (z.B. auch im AfterScroll):


Und im Hauptformular auf dieses Event reagieren:


Auf diese Art muss das Datenmodul das Hauptformular nicht kennen. Es gibt nur den Bezug in Richtung Hauptformular -> Datenmodul. In die umgekehrte Richtung gibt es keinen Bezug.

Das Datenmodul kennt auch nichts, aber die Klasse dahinter. Entweder ist das das Formular selbst, z.B. mit einem passenden Interface versehen, oder eine eigene Klasse, die die Oberfläche nur ansteuert.

Sprich:// EDIT:
Da war Nersgatt schneller, genau so.

Oder eben ein GUI Interface, das durch das Formular implementiert wird.

Nersgatt hat folgendes geschrieben :

Das Hauptformular kennt doch das Datenmodul. Also kannst Du im DM ein Event deklarieren:

Moin Nersgatt, moin Jaenicke,

diese Erklärung (insbesondere die von Nersgatt) war so gut, daß ich sie sofort und ohne jegliche Probleme erfolgreich ausprobieren konnte. Ich habe jetzt gerade in wenigen Minuten ein Datenmodul von der Referenzierung der Hauptunit befreit und es funktioniert alles einwandfrei. Das Property-Konzept kenne ich ja bereits gut, aber das man ein Event als Property eintragen kann, war mir einfach nicht geläufig. Euch beiden gebührt daher mein Dank, was ich mit zwei freudig ausgeführten Thx-Klicks bestätige.

Tranx hat folgendes geschrieben :

Also - wenn ich das so sehe - arbeite ich falsch. Liegt mit Sicherheit daran, dass ich mir die Sache selber vor 10 Jahren habe aneignen müssen. Vorher hatte ich mir OP nichts am Hut. In Turbo-Pascal war das für mich was wie böhmische Dörfer.

das ist bei mir nicht anders. Nur hat es sich halt gezeigt, dass es deutlich geschickter ist wenn sich unterschiedliche Teile nicht zu sehr aufeinander verlassen - einer der beiden könnte sich mal ändern und dann zieht sich eine, an sich kleine Änderung, durch zig weitere Units.

Tranx hat folgendes geschrieben :

Nun frage ich mich aber? Wenn ich nun die Hauptunit nicht einbinden darf, aber eine Key-Unit nur die Tastatur-Ereignisse aufnimmt, die das Hauptformular bekommt, und dies bearbeitet, dann habe ich ja gar keine Chance, ohne Einbindung der Hauptunit die Prozeduren in verschiedene Units aufzusplitten.

doch das geht - wie wurde oben ja schon gezeigt - über entsprechende Zuweisung von Events usw.

Tranx hat folgendes geschrieben :

Tja, so ist das, wenn man als totaler Laie programmiert. Kommt nur Müll raus. Danke für Eure Hinweise.

jetzt sei mal nicht so streng... da kommt kein Müll raus, nur schwer zu überschauender Code. Wenn Du damit klar kommst ist es erst mal OK - aber du hast ja oben selbst geschrieben, dass dir die Aufteilung von Projekten nicht klar ist. insofern ist dir bei der Sache doch auch nicht ganz wohl und das ist gut so - weil das der erste Schritt ist

Was wir hier beschreiben ist der aktuelle "Standard" wobei man den noch deutlich weiter ausbauen kann (Interfaces,....). Frage ist halt jetzt was du machst: dein bisheriges Vorgehen beibehalten oder anfangen Kleinigkeiten zu ändern beides hat Vor- und Nachteile.

Grüße

Perlsau hat folgendes geschrieben :

aber das man ein Event als Property eintragen kann, war mir einfach nicht geläufig.

Ein Event ist letztendlich nichts anderes als eine Property. Nur der Datentyp ist ein Zeiger auf eine Procedure. Nicht mehr und nicht weniger. Dessen muss man sich nur einmal bewusst werden.

Tranx hat folgendes geschrieben :

Tja, so ist das, wenn man als totaler Laie programmiert. Kommt nur Müll raus. Danke für Eure Hinweise.

Da möchte ich Lemmy beipflichten: Mach dich nicht selber fertig, das besorgen, wenn du's wirklich brauchst, andere für dich

Nein, im Ernst: Ich wie alle anderen hier waren ebenfalls einmal Laien. Ich selbst bin es in vielen Bereichen noch immer, da mache ich mir gar nichts vor. Auch habe ich weder Informatik studiert oder gar bereits in der Schule Programmierunterricht, noch hatte ich einen Lehrer oder Mentor, der mir Delphi beigebracht hat – alles autodidaktisch erworben, mit Hilfe von Büchern, Internetforen, Manuals und Ausprobieren. Letzteres scheint mir der effizienteste Lehrmeister zu sein ...

Nersgatt hat folgendes geschrieben :

Perlsau hat folgendes geschrieben : aber das man ein Event als Property eintragen kann, war mir einfach nicht geläufig. Ein Event ist letztendlich nichts anderes als eine Property. Nur der Datentyp ist ein Zeiger auf eine Procedure. Nicht mehr und nicht weniger. Dessen muss man sich nur einmal bewusst werden.

Genau das ist mir eben beim Umschreiben eines alten Projekts bewußt geworden. Nochmal danke dafür.

So, ich habe jetzt dieser Uses im Implementation-Abschnitt (bis auf 7) reduzieren können (ursprünglich ca. 40). Allerdings habe ich bei der Sache auch gesehen, dass Delphi-Grundlagen-Units (DB, FileCtrl, Forms, ...) selber eine Menge Uses im Implementation-Abschnitt besitzen. Konkret waren das bei allen benutzten Grundlagen-Units:

in implementation: 32 Units mit 78 Referenzen auf andere Units.
in interface: 43 Units mit 265 Referenzen auf andere Units.

und folgende Units haben Überschneidungen:

Controls/ActnList
Controls/Menus
Forms/ActnList
Forms/Controls
Forms/Menus
Menus/ActnList
Printers/Forms
StdActns/Forms

Das nur zur Info.

Weitere Reduzierungen sind m.E. nicht sinnvoll, da ich dann viel zu viel Zusammenfassungen von Units vornehmen müsste, was teilweise auch nicht sinnvoll ist, weil ich mehrere Fenster in dem Projekt habe und diese in seperaten Units verwalte. Allerdings sind diese nicht unabhängig voneinander, so dass ich die Beziehungen zum Hauptfenster, der Haupt-Unit hier komplett ausgeklammert hae. Allerdings hat die Daten-Unit nun keinen Bezug mehr zur Haupt-Unit.