Ich entwickle seit Delphi 2 sehr schnell funktionierende Anwendungen. Ich nenne das 'Rapid Application Development'. Mehr ist das doch nicht. Aber auch nicht weniger, denn das ist das Gute an Delphi, aber auch an -z.B. Visual FoxPro.
RAD ist
imho kein Paradigma, sondern ein Resultat eines so konzipierten Frameworks und der
IDE. Der Ansatz von Visual FoxPro ist z.B. ein komplett anderer, trotzdem entwickelt man Programme in kürzester Zeit.
Das mal zum Thema
RAD oder nicht
RAD (APP).
Nähkästchen: Wenn ich das 30.ste Formular erstelle und beim starten merke, das dieser nun 10 Sekunden dauert, dann denke ich darüber nach, was ich hier so treibe und räume auf. Nun ja. Eigentlich fang ich erst gar nicht an, diesen Mist zu machen, denn jede Form bekommt eine Klassenmethode zum erzeugen und anzeigen.
Delphi-Quellcode:
Type
TForm1 = Class (TForm)
...
class function Show (data :TSomeData) : Boolean;
end;
implementation
class function TForm1.Show (data : TSomeData) : Boolean;
Begin
With TForm1.Create(nil) do begin
InitData(data);
Result := ShowModal = mrOK;
if Result then WriteBackData(data);
Release;
end
end;
Ach bitte: Keine Kommentare wegen dem bösen 'With'. Take it or leave it. I take it because I know what I'm doing.
Die Routinen sehen natürlich nicht alle 100% identisch aus, aber im Prinzip sorge ich dafür, das ich mit einem Aufruf das Formular anzeige und das bisserl Logik dort verankere. Ich komme dabei zu 99% komplett ohne irgendwelche Bindings aus. Und, und darauf wollte ich hinaus: Ich komme komplett ohne Formularvariablen aus.
Damit kann ich dann sehr einfach in einem Buttonclick ein Kindformular öffnen, womit wieder 99% der Anwendungsfälle abgedeckt sind.
Die restlichen 1% (nicht modale Fenster, Threads und Statusaktualisierungen) erschlage ich mit Messages oder was mir sonst noch so einfällt. Und hier kommen dann globale Variablen ins Spiel. Ob ich diese globalen Variablen hinter einem Controller oder Container verberge, ist ja wurscht. 'Form1' ist für alle sichtbar, aber eben nur lesend. Da
handle ich nach der Maxime: Wer Dreck macht, muss aufräumen, bzw. wer Form1 instantiiert, ist dafür verantwortlich, es auf den Müll zu schmeißen. So ein Container ist hier eine gute Sache, denn über den kann jeder Thread eine bitte zur Aktualisierung seines Status an das Formular schicken. Der Container entscheidet bzw. implementiert die Technik, wie die Form das mitbekommt, so bin ich von Synchronize und Queue unabhängig.
Die Produktivität ist enorm,
RAD at its best. Nicht weil ich so toll bin, sondern weil dieses Schrottdelphi (D7, XE) es mir wirklich leicht macht.
Der Preis? Bei wachsender Komplexität wird die Anwendung sehr schnell nicht mehr leicht wartbar. Mit wachsender Komplexität ist aber nicht die Anzahl der Formulare gemeint, sondern die Businesslogik. Insofern würde ich bei großen Projekten auf
RAD pfeifen, denn unterm Strich bin ich damit nicht schneller, eher im Gegenteil.
Wenn ich aber auf irgend ein Riesenformular den 1000 Menüpunkt unterbringen soll, der noch ein Fenster aufmacht (Herr, schmeiss Hirn vom Himmel), dann mache ich genauso weiter (
RAD, klick, bunt) , denn komplexer wird die Applikation dadurch ja nicht. Nur noch schlechter bedienbar.
Abschließend will ich noch etwas loswerden: Ich bin froh, das man hier doch sehr hochwertige Beiträge findet. Die Aktivität der letzten Tage deuteten eher auf ein ziemlich eingeschlafenes Forum hin.
