Ordentlicher Aufbau eines Programms u. der Klassen

[Pfoto]

Hallo zusammen,

ich mache zwar (auch Dank des Forums) immer mehr Fortschritte und mein Programm tut auch schon vieles was ich will, aber ich befürchte, dass ich noch keinen ordentlichen Aufbau habe.

Nun habe ich viele Prozeduren nach logischen Gesichtspunkten selbst erstellten Objekten untergeordnet, aber ich bin mir nicht sicher, ob mein Gedankenweg richtig ist.

Sollte man eine Hauptklasse erstellen, die wiederum andere Klassen enthält?
also z.B.
- TMeinProgramm
---- TSettings
------- TKonstante
------- TUserEinstellungen
---- TUserInterface
---- TDatenbankzugriff
etc.
und dann das Ganze bei Form.Create TMeinProgramm erstellen

Oder reicht es, die Klassen/Objekte einfach einzeln in einer Unit zu haben und diese dann alle nacheinander in Form.Create bzw. bei Bedarf zu erstellen?
Auch weiß ich nicht, ob die Klassen innerhalb des Hauptformulars deklariert werden sollten, so dass sie praktisch alle zum Objekt Hauptformular(TForm) gehören. Oder ist das "Geschackssache"?


Noch ein Problem:
Die Ausgabe im MainForm möchte ich ja auch über die Objekt-Methoden machen.
Sollte ich da einfach den Pointer einer MainForm-Komponente als Parameter übergeben, so dass das Objekt direkt darauf zeichnet (z.B. DrawText(AForm: TForm) oder eher Ereignisse auslösen, die wiederum im Hauptprogramm abgefangen werden?


Wie handhabt ihr das? Auch Links zu Tutorials, Büchertipps etc. sind willkommen.
Vielen Dank im Vorraus.


Gruß
Pfoto

[SirThornberry]

der richtige ansatz ist der den du skiziert hast. Also das du nur TMeinProgramm erstellst und dieses dann nur TSettings etc. erstellst. In TSettings muss dann im Constructor das erstellt werden was dort dazu gehört.
Der Grund ist auch recht einfach. TKonstante und TUserSettings wird IMMER gebraucht wenn du TSettings brauchst also ist es auch sinnvoll dies in TSettings zu erzeugen (Denn wenn du TSettings außerhalb von TMeinProgramm mal brauchst müsstest du ja sonst TKonstante etc. wieder von Hand erzeugen obwohl es ja sowies immer gebraucht wird im Zusammenhang mit TSettigns)

[igel457]

Ich mach das genauso.

Zum Beispiel:

Delphi-Quellcode:

-TGame.Create <---------
---TSpielfeld.Create   |
-----Background.Create |
-----Einheit.Create    | 
-------OnClick-------->|
---TBackgroundMusic.Create

Wenn nun eine Einheit angeklickt wird, schleife ich dies über Events bis an mein Game weiter.

Ich denke allerdings wie du das nun im einzelnen machst ist Wurscht und "Geschackssache" .

TGame erzeuge ich eben dann wenn mein Spiel beginnen soll. Vorteil ist das du nur ein Objekt braust, das sich dann automatisch um alles kümmert, im Normalerweise ist das ja eigentlich das Formular.

(SirThornberry war leider früher als ich)

[Der_Unwissende]

Hi,
ich glaube einen gewissen Anteil "Geschmackssache" hast du natürlich auch in der OOP. Aber halt nicht alles ist Geschmackssache, ein Teil ist auch Idee und Erfahrung.
Prinzipiell lohnt es sich immer sehr modular zu arbeiten. Einerseits kannst du kleine Units die eine mächtige, tolle, schöne Klasse enthalten auch mehr als einmal verwenden. Wenn du allerdings eine riesige Toolsammlung in einer Unit mit zusätzlich noch 3 Formularen (mal ganz übertrieben) hast, dann hast du keinen Überblick mehr und wirst eher dazu neigen eine Klasse neu zu schreiben. Copy und Paste mit mehreren Klassen in einer Datei ist auch nicht zu empfehlen.

Zudem sollte jede Klasse immer nur das enthalten, was wirklich zusammen gehört. Und damit sollte deine Hauptanwendung / dein Hauptformular nur zur Anzeige dienen. Alles was berechnet wird (mal sehr abstrakt für alle Aktionen), sollte gekapselt sein. Natürlich musst du dazu immer noch im Konstruktor Instanzen erzeugen, aber bei einem Event werden dann halt nur ganz wenige Methoden einzelner Instanzen aufgerufen.
Damit bleibt dein Code gut schlank und damit auch leicht verständlich und lesbar. Großer Code mit ganz vielen tollen Zeilen in einer Unit beeindruckt natürlich gar keinen (schon gar nicht beim Verstehen, Verändern oder Fehlersuchen).

Aber auch wenn du dir die Grundsätze von OOP anguckst, geht es vorallem darum, dass jedes Objekt ein Teil von einer Welt ist. Dabei soll ein Objekt nach aussen immer eine Black-Box sein und vorallem nur den Teil der Welt kennen, der für dieses Objekt wichtig ist. Deshalb ist auch deine Struckturierung total richtig gewählt. Es sollten immer nur die Teile zusammenkommen, die zusammen gehören. Hat wirklich viele Vorteile wenn man das Konsequent durchhält.

Gruß Der Unwissende