Sinnvoller Aufbau größerer Projekte

[everdream]

Hallo,

weil ich momentan oft Probleme habe, meine Klassen, meine Form(en), etc. anständig zu organisieren, habe ich mich entschlossen, da mal die Profis zu fragen.

Ich stehe dabei meißtens vor folgendem Problem:
Soweit ich weiß, ist es üblich und auch sinnvoll, ein Hauptprogramm zu haben, das alle anderen Dinge, also Klassen, Formen, usw. verwaltet. Allerdings weiß ich nicht, wie ich das dann genau aufbauen kann. Das "normale" Hauptprogramm ist ja einfach die erste Form.
Meine Frage wäre also, wie ich ein Hauptprogramm anlegen kann, das beim Programmstart zuerst ausgeführt wird, obwohl es nicht die FormUnit ist, mit der das Projekt angefangen wurde.

Ich hoffe, ich konnte das einigermaßen erklären...

Vielen Dank schonmal für eure Antworten! :dp:

[Dani]

Plane dein Projekt erst durch, bevor du mit der Codierung anfängst. Für dein "Hauptprogramm" (vielleicht meinst du damit sowas wie einen Controller) könntest du dir mal den ActionManager anschauen. Wenn der in Delphi ähnlich gut in die VCL integriert ist wie in Java, könnte er dir helfen, deine Projekte übersichtlich zu halten.

[everdream]

Vllt ist meine Idee in Quellcode noch besser zu verstehen:

Delphi-Quellcode:

unit mMainProgram;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, mMeineKlassen, mSonstwas, mForm1, mForm2;

type
  TProgramm = class(TObject) //Das Programm soll natürlich keine Klasse sein, aber ich weiß grade nich, wie ich das besser ausdrücken sollte...
  private
    Form1: TForm1;
    Form2: TForm2;
    TMeineKlasse1;
    TMeineKLasse2;
    Array: Array[1..5,1..4] of irgendwas;
    procedure OnProgrammStart;
    [...]
  end;

implementation

{$R *.dfm}

procedure OnProgrammStart;
begin
  Form1:=TForm1.Create;
  Form1.show;
end;

procedure Form1.Button1OnClick;
begin
  Array[1,4]:=irgendwas1;
end;


procedure Form2.Button1MouseMove;
begin
  Form2.ShowMessage('Finger weg von der Maus!');
end;

end.

So könnte ich halt alles relativ einfach verwalten. "Hier laufen alle Fäden zusammen"...
Meine Idee war halt, dass ich die Formen von da aus anzeige und die darauf gemachten eingaben im Hauptprogramm verarbeiten, ohne, dass die form da noch irgendwas mit zu tun hat.

[InfixIterator]

Bei größeren Projekten muss man Projekt Management machen ;)
Am besten alles aufschreiben was benötigt wird und es sinnvol modelieren, dabei kann Dir UML weiter helfen.
Hier ist eine schöne Notationsübersicht von UML: UML Notationsübersicht
Falls dein Projekt doch kleiner ausfällt, lohnt es sich aber auf jedenfall vorher zu überlegen, wie die Anforderungsdefinitionen sind und welche zusammenhänge zwischen Funktionen, Klassen, Modulen etc. herschen soll.


Zu deiner anderen Frage:
Du kannst doch die erste Form auch als Hauptprogramm machen...
verstehe da nicht genau dein Problem...
Du kannst ja später auch neue Forms öffnen mit z.b.:

Delphi-Quellcode:

form2.show;

[everdream]

UML ist ne gute Möglichkeit sich einen Überblick zu verschaffen und eventuell kleine Denkfehler auszuradieren, bevor man anfängt, stimmt!

Zitat:

Zitat von InfixIterator

[...]
Du kannst doch die erste Form auch als Hauptprogramm machen...
verstehe da nicht genau dein Problem...
Du kannst ja später auch neue Forms öffnen mit z.b.:

Delphi-Quellcode:

form2.show;

Hm, finde das aber irgendwie unschön... Ich hätte halt lieber so eine Art """Meta-Ebene""", von der aus ich das ganze "Geschehen" steuern kann. Also von wo aus ich auf alle Formen und alle Klassen der oberen Ebene (also die, die ich vom Hauptprogramm aus direkt anspreche, die aber eventuell selbst nochmal andere Klassen verwenden) zugreifen kann.

Wäre imho auch sehr übersichtlich.

[angos]

Hi,

du hast doch dein Hauptprogramm wovon alle anderen Forms aufgerufen werden.
Das ist die .dpr-Datei. In dieser kannst du ganz normalen Delphi-quellcode schreiben, welcher ALS ERSTES NACH DEM ÖFFNEN DER EXE ausgeführt wird.

bei neuanlage sieht die so aus:

Delphi-Quellcode:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

das kann man auch schön nutzen um startparameter abzufragen und was weis ich nit ;) dürfte abr genau das sein was du suchst

beispiel:

Delphi-Quellcode:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TForm2, Form2);

  if Irgendetwasgesetzt then
  begin
    Form2.Showmodal;
    Form2.Release;
  end

  else
  begin
    Form1.Showmodal;
    Form1.Release;
  end

end.

[everdream]

:roteyes: Ui, genau sowas meinte ich.
Aber das ganze benutzt ja die Formen nicht wie normale Klassen, sondern ruft sie einfach nur auf, oder kann ich da auch ganz normal Forms per Variablendefinition einsezen?

[arbu man]

Klar geht das:

Delphi-Quellcode:

TMainForm = class(TForm)
private
  FSubForm: TSubForm;
public
  procedure ShowSubForm;
end;

...

procedure TMainForm.ShowSubForm;
begin
  if not Assigned(FSubForm) then begin // Überprüft ob FSubForm geladen wurde
    Application.CreateForm(TSubForm, FSubForm); // Lädt FSubForm 
    // alternative Application.CreateForm
    FSubForm := TSubForm.Create(Self);
  end;
  FSubForm.Show;
end;

Allerdings solltest du dir die Grundlagen der OOP anschauen, das wird dir weiterhelfen...

Edit: Du kannst in Delphi auch ein DatenModul anlegen, darin kannst du Formen und Daten verwalten über die Projekt Optionen kannst du Einstellen, das nur das DatenModul geladen werden soll.

mfg, Björn

[everdream]

hm, gerde da hatte ich mich ja gefragt, ob das in der .dpr geht...

Da wird nämlich kein Speicher für die Instanz der Klasse TForm1 reserviert, sie wird einfach aufgerufen...

Delphi-Quellcode:

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Könnte ich das ganze dann in etwa so lösen...

Delphi-Quellcode:

program Project1;

uses //"Forms" werden hier nicht mehr gebraucht...
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateClass(TMeinHauptprogramm, Hauptprogramm); //...???
  Application.Run;
end.

+

Delphi-Quellcode:

type
  TMeinHauptptogramm = class
  private
    Form1: TForm1;
    Form2punkt1, Form2punkt2: TForm2;
    //[...]
  public
    //[...]
end;

[angos]

müsste theoretisch auch gehen, aber dann musst du dich um das ganze erzeugen der form usw kümmern.. Objektorientiert ist shcön und gut und meiner meinung nach absolut wichtig, aber da wirds glaub ich etwas übertrieben ;)

probiere damit aber ruhig zu testzwecken einfach mal ein bissl rum, aber mehr übersicht bringt dir das, denke ich, nicht.


Gruß

[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