Sinnvoller Aufbau größerer Projekte

[alzaimar]

Das Framework von Delphi bei GUI-Anwendungen ist doch in Ordnung, findest Du nicht? Ich persönlich versuche, nur die MainForm beim Programstart zu erzeugen, also so:

Delphi-Quellcode:

Application.Initialize;
Application.CreateForm (TMainForm, MainForm);
Application.Run;

Das Hauptformular ruft beim erstmaligen Anzeigen eine 'ApplicationInitialize'-Routine auf, die die Datenmodule anlegt, Verbindungen zur Datenbank prüft und anlegt, etwaige Bildchen und sonstwas aus den Resourcen lädt etc. Dabei kann ein Splash angezeigt werden, sodaß das ganze auch visuell ansprechend ist.

Was die ganze Logik anbelangt, kommst Du um Planung, Erfahrung und waschechtes und 100% durchgezogenes OOP nicht herum. Ich kann mich zwar mit isolierten Prozeduren, Funktionen und globalen Variablen im Rahmen eines kleinen bis mittleren Frickelprojektes (RAD) anfreunden, aber bei komplexen Anwendungen kann man das auch in eine 'TGlobalStuff'-Klasse auslagern bzw. gleich richtig zuordnen.

Weiterhin würde ich mich bei noch größeren Anwendungen auch mal mit SOA auseinandersetzen.

Kannst Du mir erklären, wieso Du ein Objekt willst, bei dem 'alle Fäden zusammenlaufen'?

[everdream]

Naja, liegt das nicht auf der Hand?

Wenn ich ein Objekt habe, das wirklich alles enthält, was das Programm benutzt, dann kann ich doch von da aus alles am besten regeln.
Ich rufe "nur noch" einige Prozeduren und Functionen auf, verwalte so Anzeigeelemente und Logik des Programmes. Das ist ja das schöne an OOP, man schreibt sich seine Klassen, die schon viel selbst machen, dann muss man sie nur noch verknüpfen und alles läuft super. Und alles an einem Punkt zusammenlaufen zu lassen ist der einfachste Weg.

[Bernhard Geyer]

Zitat:

Zitat von everdream

Wenn ich ein Objekt habe, das wirklich alles enthält, was das Programm benutzt, dann kann ich doch von da aus alles am besten regeln.

Und damit ein Gott-Objekt erschaffst. Ist nicht gerade sehr übersichtlich und wartbar.

[everdream]

Wenn die Klassen viel selbst machen, dann muss mein "Gob-Object" ja nicht so umfangreich sein...

außerdem: wenn ich von meiner Form1 aus die versch. Objekte und die anderen Formen verwalte kommt das doch auf's gleiche raus, nur, dass ich den Code für die Form noch mit drin hab.

[Bernhard Geyer]

Wenn du ein größeres Projekt angehst ist es sinnvoll erstmal den PC ein paar Tage auszuschalten, einen (karierten) Block zu nehmen, 3-4 Stifte zur Hand zu haben und sich erst mal IDE-/Programmiersprachen-/Frameworkunabhängig Gedanken zu machen.

[Tyrael Y.]

Ich glaube du möchtest einen Plugin-Manager benutzen und weisst es nur noch nicht :D

- du rufst dein Hauptformular auf
- in deinem Hauptformular kreierst du einen Plugin-Manager
- je nach dem was gerade angezeigt werden soll, lädt der Plugin-Manager die von dir gewünschten Plugins und zeigt sie, falls sie aus Frames/Formularen bestehen an

- was nicht mehr gebraucht wird, gibt dein Plugin-Manager wieder frei

Letzendlich hast du eine sehr kleine Programm.exe, die bei einer Formularanwendung aus einem einzigen Formular besteht. Alles andere wird dynamisch durch den Plugin-Manager geladen.

Alle deine Plugin sind daher also DLL´s die zur Laufzeit geladen werden können und zentral durch einen Plugin-Manager kontrolliert werden.

Wenn du mal im Forum unter Plugin-Manager nachguckst oder mal im Netz, wirst du noch viel mehr Infos dazu finden.

Grüße