Viele proceduren auf Form auslagern ?

[HolgerCW]

Hallo zusammen,

ich habe auf einer Form viele Buttons, DBGRids, Pages u.s.w., die Ereignisse mit den dazugehörigen Proceduren habe ich alle im Code dieser Form abgelegt.
Jetzt habe ich dort über 10.000 Zeilen und es wird sehr langsam. Wie kann ich nun am besten die procedure auf mehrere Units oder was anderem verteilen ?

1. Wenn ich einfach eine Unit anlege, unter uses die Form angebe, und dann mal eine procedure kopiere klappt es nicht.
2. Natürlich könnte ich auch in den Ereignis-Proceduren auf procedure, welche in anderen Units liegen verweisen, aber ich denke das ist nicht sinn der Sache, oder ?

Gruss

Holger

[mkinzler]

Das ist sogar Standard bei großen Projekten. Nennt sich MVC, also strikte Trennung von Daten, Oberfläche und Logik.

[Gruber_Hans_12345]

Zitat:

Zitat von HolgerCW

Hallo zusammen,
Jetzt habe ich dort über 10.000 Zeilen und es wird sehr langsam. Wie kann ich nun am besten die procedure auf mehrere Units oder was anderem verteilen ?

1. Wenn ich einfach eine Unit anlege, unter uses die Form angebe, und dann mal eine procedure kopiere klappt es nicht.
2. Natürlich könnte ich auch in den Ereignis-Proceduren auf procedure, welche in anderen Units liegen verweisen, aber ich denke das ist nicht sinn der Sache, oder ?

Gruss

Holger

... nur wird sich geschwindigkeitsmässig nichts ändern, da kannst wahrscheinlich auch 1 million zeieln in einem form haben, sobald das kompiliert ist, dürfte es egal sein, ob der code von einem oder von tausenden formularen kommt - oder meinst die IDE ?

[HolgerCW]

Zitat:

Zitat von mkinzler

Das ist sogar Standard bei großen Projekten. Nennt sich MVC, also strikte Trennung von Daten, Oberfläche und Logik.

-> Und wieso wird, wenn ich einem Ereignis, Code hinterlegen möchte, auf die Form verwiesen ?
-> Muss ich also immer eine Unterprocedure, in der Ereignis-Procedure anlegen ?

Zitat:

... nur wird sich geschwindigkeitsmässig nichts ändern, da kannst wahrscheinlich auch 1 million zeieln in einem form haben, sobald das kompiliert ist, dürfte es egal sein, ob der code von einem oder von tausenden formularen kommt - oder meinst die IDE ?

-> Das ist korrekt, nur beim bearbeiten des Codes rechnet der Computer sich zu tode.

Gruss

Holger

[SirThornberry]

-> Und wieso wird, wenn ich einem Ereignis, Code hinterlegen möchte, auf die Form verwiesen ?
Das verstehe ich nicht :gruebel:

-> Muss ich also immer eine Unterprocedure, in der Ereignis-Procedure anlegen ?
richtig

[alias5000]

MVC lässt sich mit den Mitteln der OOP (objektorientierten Programmierung) leichter realisieren, als mit Prozeduraler Programmierung, behaupte ich jetzt mal.

Wenn du noch nicht auf OOP bist, könnte das ein erster Schritt sein

gruß
alias5000

[Luckie]

Hallo Holger,
du scheinst ein grundsätzlichen Design-Problem zu haben. Wie mkinzler schon sagte, sollte man den Code zur Manipulation der Daten und den Code für die Visualisierung strikt trennen. Dies gelingt, meiner Meinung nach, am Besten, wenn man den Code zur Manipulation der Daten in Klassen organisiert. In den Ereignisprozeduren der Kontrolelemente werden dann nur noch die Methoden der Klassen aufgerufen. Ein schönes Beispiel ist eventuell mein kleiner, einfacher Memory-Clone: http://www.delphipraxis.net/internal...ghlight=memory bzw. http://www.delphipraxis.net/internal...=760927#760927

[pstruh]

Hallo Zusammen,
mir fällt in diesem Zusammenhang spontan die Möglichkeit ein, Code in Include-Dateien auszulagern. Damit schafft man zumindest optisch eine oft bessere Übersicht, da die jeweiligen Dateien nicht mehr so ellenlang sind. Wird diese Möglichkeit der Code-Aufteilung von "Profis" heute eigentlich noch verwendet, oder ist das eher als Relikt aus uralten Zeiten anzusehen?
Gruß aus Hamburg

[mkinzler]

@pstruh: Meinst du MVC oder die Includes?

[pstruh]

.. die Includes

[Ghostwalker]

Die Includes sind eher Relikte aus alten Zeiten. Das einzige, wozu sie heute noch verwendet werden soweit mir bekannt ist, sind die Compilerschalter für die Units (z.B. JCL,JVCL). Zum Auslagern von Ereignissprozeduren/-funktionen sind sie nicht geeignet. Wie Luckie schon geschrieben hat, am besten über OOP.

[pstruh]

Ja, das habe ich schon vermutet; die Includes führen ja nur zu einer "optischen" Auslagerung und sind dadurch selbstverständlich überhaupt nicht mit einer Klassenbildung zu vergleichen - OK!
Aber vielleicht noch mal zur Vertiefung des Themas und den Denkansätzen von MVC: In Wikipedia gibt's da ja einen allgemeingültigen Text, der mich leider eher irritiert. Der "normale" Umgang mit dem Delphi-Formular führt m.E. eher zu einem dem MVC gegenteiligen Ergebnis. Das grundsätzlich Vorgehen ist doch, dass alle Daten, deren Steuerung und auch die Optik des Formulars quasi automatisch immer in der dem Form zugehörigen Unit angelegt werden. Wenn ich das auch nur annähernd richtig verstehe, dann müsste man doch im Sinne von MVC gerade diese "Automatik" verlassen, oder?
Gruß aus Hamburg

[mkinzler]

Ja. Man müsste die Daten( Model), die GUI (View) und die Logik (Controller) strikt trennen.

[Luckie]

Nun ja, die Delphi-IDE verführt schon dazu Daten und Visualisierung nicht zu trenne. Man packt eine Schaltfläche auf das Formular, macht einen Doppelklick auf die Schaltfläche und landet automatisch in der von der IDE erzeugten Ereignisprozedur. Und gerade Anfänger, ich spreche da aus eigener Erfahrung, werden dann dazu verleitet dort ihren Code hinzuschreiben. Am Ende hat man dann genau das Problem, welches Holger hier anspricht.
Der erste Schritt, der weg von diesem Programmierschema führt, ist der Aha-Effekt, den man hat, wenn man identischen Code in zwei Ereignisprozeduren hat und feststellt, dass man dafür eine eigene Methode in der Form-Klasse erstellen kann und diese dann in beiden Ereignisprozeduren aufruft. Der nächste Schritt ist dann wirklich die strikte Trennung von Daten und Visualisierung. Und wie gesagt, dies gelingt am einfachsten in dem man konsequent mit Klassen arbeitet.

[HolgerCW]

Hi,

jetzt bin ich auf jeden Fall schlauer. Ich bin nämlich einer derjenigen, die erst seit kurzem mit Delphi arbeiten.

Zitat:

Der erste Schritt, der weg von diesem Programmierschema führt, ist der Aha-Effekt, den man hat, wenn man identischen Code in zwei Ereignisprozeduren hat und feststellt, dass man dafür eine eigene Methode in der Form-Klasse erstellen kann und diese dann in beiden Ereignisprozeduren aufruft

-> Das habe ich nämlich nur bei identischem Code gemacht

Werde mir jetzt mal das Klassenthema zu Herzen nehmen.

Vielen dank nochmal.

Gruss

Holger