Kaspall - Mi 22.12.10 17:25
Titel: Code richtig auslagern

---

Hallo, ich hab folgendes Problem:

Um mein Programm etwas übersichtlicher zu gestaltet würd ich gern Teile des codes auslagern: Gut, ich weiß wie man Funktionen/Proceduren in andere units steckt oder auch in DLLs,
also GRDUNSÄTZLICH kein Problem.

Das Problem das sich mir stellt ist das alle meine Proceduren auf globale Variablen und Komponenten der Exe-Hauptunit mit der Form zurückgreifen. Wenn ich jetzt eine neue Unit2 mache kann ich dort in die uses unit1 reinschreiben, dann kann aich das alles schön verwenden, aber wenn ich dann in der Unit1 unter uses Unit2 dazuschreibe verstreut Delphi beim Kompilieren Fehlermeldungen raus.

Und ja, ich weiß ich kann Variablen übergeben, nur sind in meinem Programm ca pro Procedure ca 200-300 Stück und das geht mir echt gegen den Strich das alles einzeln zu übergeben =)
Es muss doch eine Lösung für dieses "einfache" Problem geben.

lg kaspall


Moderiert von Narses: Topic aus VCL (Visual Component Library) verschoben am Mi 22.12.2010 um 22:28

Gausi - Mi 22.12.10 17:33

---

200 Variablen in einer Prozedur? Wie lang sind die denn? :shock: Es gibt hier Leute, die der Meinung sind, dass eine Prozedur nie länger als ein oder zwei Bildschirmseiten sein sollten - da passen 200 Variablen gar nicht rein.

Sieht nach einem sehr grundlegenden Konzeptproblem aus. Strukturiere dein Programm besser, verwende mehr und dafür kürzere Prozeduren und Funktionen. Trenne die Darstellung im Fenster von den eigentlichen Daten und Variablen. Verwende Klassen, die einen Teil der Aufgaben selbst erledigen (OOP halt). Oder fasse zumindest ein paar Variablen in Records zusammen.

jaenicke - Mi 22.12.10 17:38

---

Kaspall hat folgendes geschrieben :

Komponenten der Exe-Hauptunit mit der Form zurückgreifen

Ja, es ist auch nicht gut auf visuelle Komponenten außerhalb der GUI zuzugreifen. Für die visuelle Darstellung ist die GUI verantwortlich, für die Daten und die Logik ein anderer Teil des Projekts.

Das solltest du zumindest ein wenig trennen. Das geht wie Gausi schon geschrieben hat mit OOP z.B. recht gut. Das macht das ganze auch gleich viel übersichtlicher.

Schau dir z.B. einmal das MVC-Konzept an:
http://de.wikipedia.org/wiki/Model_View_Controller
(Es muss ja nicht gleich so formal sein, aber die Idee ist das entscheidende.)

Jakob_Ullmann - Mi 22.12.10 18:23

---

Gausi hat folgendes geschrieben :

200 Variablen in einer Prozedur? Wie lang sind die denn?

Mir tut vor allem der Stack leid, der das dann alles aufnehmen muss.

Zu dem Problem mit dem Uses: das kannst du lösen, indem du in Unit2 die Unit1 in die uses-Klausel im interface-Teil aufnimmst. In Unit1 integrierst du Unit2 aber über die uses-Klausel im implementation-Teil, so wie Delphi das automatisch macht, wenn du auf Formulare in anderen Units zugreifst.

jaenicke - Mi 22.12.10 18:27

---

Diese "Lösung" hatte ich jetzt absichtlich nicht genannt. ;-)

Das führt nur dazu, dass am Konzept nichts verbessert wird und die Unübersichtlichkeit nur ein wenig auf mehrere Units verteilt wird und damit noch unübersichtlicher wird.

Chemiker - Mi 22.12.10 19:50

---

Hallo Kaspall,

Zitat:

Und ja, ich weiß ich kann Variablen übergeben, nur sind in meinem Programm ca pro Procedure ca 200-300 Stück

Donnerwetter, hast Du Dir vorgenommen in das Guinness-Buch der Rekorde zu kommen? Jetzt mal im ernst, wie behältst Du da den Überblick? Vielleicht stellst Du hier mal eine Procedure ein die 300 Variablen benutzt.

Bis bald Chemiker

Jakob_Ullmann - Mi 22.12.10 20:04

---

Möglicherweise wäre es hier angebracht, entweder mit globalen Variablen oder mit records zu arbeiten. 300 Argumente sind jedenfalls 290 zu viel.

Delete - Mi 22.12.10 20:46

---

Jakob_Ullmann hat folgendes geschrieben :

Möglicherweise wäre es hier angebracht, entweder mit globalen Variablen oder mit records zu arbeiten. 300 Argumente sind jedenfalls 290 zu viel.

Bitte nicht. 200 bis 300 globale Variablen? Das ist schon Folter für denjenigen, der das Programm mal warten soll. Außerdem ist von der Genfer Konvention verboten.

Strukturiere dein Programm besser. Nutze Klassen, denen du die erforderlichen Daten als Properties übergibst, wenn sie in mehreren Methoden benötigt werden.

Und eventuell solltest du dir mal den Datentyp Arry angucken.

Kaspall - Do 23.12.10 00:11

---

Lol, also um aufzuklären, ich schreib hier ein Grafikprogramm mit OpenGL, und da ergeben sich halt schnell mal mehrere booleans, Zahlen und nen haufen Objekte meiner bereits 20 Klassen. Grad die Rendermethode(n) habens massiv in sich und fressen das Zeug das es nur so raucht! Hab hier ne 1200-Zeilen-Methode!

hehe, hab mich sehr ammüsiert über eure Antworten^^. und danke für den Tipp mit dem richtigen uses^^

Dude566 - Do 23.12.10 00:23

---

1200 Zeilen :shock: , das lässt sich bestimmt auch kürzer bzw. in kleinere Methoden unterteilen oder?

Delete - Do 23.12.10 00:53

---

Kaspall hat folgendes geschrieben :

Hab hier ne 1200-Zeilen-Methode!

Jede Wette, so bald du ein Problem bekommst, wirst du dich freuen wenn du diese 1200 zeilen debuggen darfst.

Bergmann89 - Do 23.12.10 11:40

---

Hey,

ich arbeite auch relativ oft mit OpenGL, und ich hab noch nie ne Render-Prozedur über 1000 Zeilen hin bekommen. Ich bin genau der gleichen Meinung wie meine Vorredner: man kann das alles in Klassen organisieren. Mein 1. OpenGL Programm war auch totales Chaos und da ich die das Ganze ersparen will, geb ich dir den Rat: Denk nochmal über dein Konzept nach. Wenn das möglich is kannst du die Unit (oder nur ne TXT mit der Render-Prozedur) auch mal hochladen, da könn wir dir sicher ein paar Tips geben.

MfG Bergmann.