Grosse Programme "übersichtlich" programmieren

[taaktaak]

Moin, Moin.
Vor einigen Wochen gab es hier im Forum einmal ein Stichwort, zum Thema, wie man größere Programmieraufgaben übersichtlicher gestalten kann. So im Sinne von Trennung von Optik, Funktion und ???.
Ich finde das nicht mehr und kann mich auch an das Stichwort nicht mehr erinnern. Zur Zeit bastle ich an einem Programm, welches nun schon fast 5000 Zeilen für ein Formular hat - die Übersicht fällt mir dabei immer schwerer. So bin ich an diesem Thema sehr interessiert. Leider habe ich keine Informatik studiert und brauche jetzt eine kleine Initialisierung von Profis ...
Gruß
Ralph

[arbu man]

Stichworte wäre UML und OOP

Aber versuche dein Projekt Möglichst Modular zu programmieren, module können sein (Haupt GUI, Einstellungen). Teile es in Teile ein die autak sind. Benutzen Klassen und Vererbung (also die Features der OOP) auch kann es Hifreich sein wichtige/großen Funktionen noch einmal in mehere Funktionen zu aufzuteilen. Wichtig ist es auch gleichartige stellen imSource/Design zusammen zufassen, bei Formularen kann man das mit Frames oder Komponenten erreichen und im SOurce kann man wiederkehrende Stellen durch Funktionen erstzen.
Das alles ermöglicht auch die Wiederverwendung des Sources in späteren Projekten.

mfg, Björn

[taaktaak]

Hallo Björn, vielen Dank für die rasche Antwort!
Hmm, also über UML habe ich jetzt einiges in WIKI gelesen, aber ehrlich gesagt nix verstanden.Ist dort verständlicherweise sehr abstrakt formuliert. Bliebe noch OOP: Ja klar, diverse Funktionalitäten die das Programm benutzt sind schon in Klassen "ausgelagert".
Mein Versuch den Source "optisch zu entzerren" hat mich dann verleitet es so wie vor 20 Jahren zu machen: Ich habe funktional zusammenhängende Teile in Include-Dateien ausgelagert - aber damit verliere ich die Unterstützung der IDE zwischen den Procs und deren Aufrufen hin- und her zu springen. Das habe ich also wieder zurückgenommen.
Tja, blieben noch die Frames - sagt mir erst einmal gar nix. Werde mir das mal in Ruhe anschauen
Gruß und Gute Nacht
Ralph

[taaktaak]

Hallo Zusammen; möchte noch mal "nachlegen":

Weder Frames noch ActionList scheinen mir weiterzuhelfen. Im Anhang habe ich mal einen ScreenDump meines Programmes beigefügt: Auf der linken Seite befindet sich ein PageControl mit 3 Pages: Auswahlfenster für Texte, Auswahlfenster für die History-Funktion, Auswahlfenster für die Textsuche. Auf der rechten Seite die Textanzeige und der Texteditor. Also 5 Grundfunktionalitäten. Insgesamt sind auf diesem Form so etwa 160 Objekte enthalten. Auch wenn manche Buttons, MainMenus und PopUpMenus die gleichen Methoden nutzen, kommt da 'ne Menge zusammen. Und Delphi führt mich ja immer dazu, die Methoden auch in der Unit des Forms anzulegen.

Hmmm, bin ich da jetzt begriffsstutzig? Aber wie kann mir OOP da helfen?

Oder sollte ich aus den Methoden, die immer in der Unit des Formulars "landen" wiederum Methoden aufrufen, die dann in einer anderen Unit "ausformuliert" sind?

Wäre nach wie vor über einige praktische Anregungen dankbar (wie schon erwähnt, habe zwar studiert, aber nicht Informatik - daher fehlt mir leider viel zu oft die intellektuelle Basis)

Gruß Ralph

[freak4fun]

Zitat von taaktaak:

Hmm, also über UML habe ich jetzt einiges in WIKI gelesen, aber ehrlich gesagt nix verstanden.Ist dort verständlicherweise sehr abstrakt formuliert. Bliebe noch OOP: Ja klar, diverse Funktionalitäten die das Programm benutzt sind schon in Klassen "ausgelagert".

UML und OOP schließen sich nicht aus. Man kann mit UML die Klassen grafisch designen und dann den Code erzeugen lassen (Hab das allerdings noch nich gemacht. ).

Zitat von taaktaak:

Ich habe funktional zusammenhängende Teile in Include-Dateien ausgelagert - aber damit verliere ich die Unterstützung der IDE zwischen den Procs und deren Aufrufen hin- und her zu springen.

Meinst du damit Units? Da geht eigentlich nichts verloren.

Hast du mal die GUI von deinem Programm zur Hand? Vielleicht kann man da was in Units/Formulare auslagern, was du so noch nicht probiert hast. Das kling alles ein wenig nach Umstellung von prozeduraler Programmierung auf OOP, was meiner Erfahrung nach sehr große Schwierigkeiten in der Denkweise der Programmierer selbst hervorruft. Falls das der Fall ist, keine Angst. Das wird schon Dchritt für Schritt.

[edit][dp="großes Projekt"]großes Projekt[/dp]Einfach mal stöbern. [/edit]

MfG
freak

[Bernhard Geyer]

Zitat von freak4fun:

Zitat von taaktaak:

Ich habe funktional zusammenhängende Teile in Include-Dateien ausgelagert - aber damit verliere ich die Unterstützung der IDE zwischen den Procs und deren Aufrufen hin- und her zu springen.

Meinst du damit Units? Da geht eigentlich nichts verloren.

Ich denke schon das er Include-Dateien meint. Jedoch sollten diese m.E. nur für Compilerdirektiven und ähnliches verwendet werden. Für alles andere richtige Units. Include-Dateien von Delphi kann man nicht mit include-Dateien von C/C++ vergleichen.

[Hansa]

Zitat von taaktaak:

..Bliebe noch OOP: Ja klar, diverse Funktionalitäten die das Programm benutzt sind schon in Klassen "ausgelagert".
Mein Versuch den Source "optisch zu entzerren" hat mich dann verleitet es so wie vor 20 Jahren zu machen: Ich habe funktional zusammenhängende Teile in Include-Dateien ausgelagert - ...

INC-Dateien für Source ? Siehe Bernhard. Das habe ich für einen Zweck mal benutzt : um bei BP 7 die Grenze des Quelltextes pro Unit über 64 KB zu hieven, weil es wirklich, zumindest sinnvoll, nicht mehr anders ging. Betrifft eine einzige Unit, die die EXE dadurch nicht vergrößert hat. Bei dir scheint so was aber vielfach mitcompiliert zu werden und ob der Linker da die Gemeinsamkeiten tatsächlich erkennt und notfalls wegoptimiert, das wage ich ernsthaft zu bezweifeln.

[alzaimar]

Ich würde zunächst einmal so vorgehen:
1. Konsistente Benennung von Units, Klassen, Objekten, Feldern, Variablen
Überlege Dir eine einheitliche Namensgebung für alle Teile deines Projektes. Im Idealfall soll man im Code sofort erkennen, ob es sich um ein Feld, einen Parameter oder eine lokale Variable handelt. Schaue Dir z.B. die VCL an und versuche, die Systematik hinter der Benennung zu finden. Verwende für die Benennung der Konstrukte eine einheitliche Sprache, die DU am besten kannst, und der Leser vermutlich versteht. Verwende auch eine einheitliche Grammatik für Prozeduren: Entweder immer 'KundenSpeichern', 'KundenLaden' oder immer 'SpeichereKunden', 'LadeKunden'.
Denk nicht, das englische Namen professioneller sind. Manchmal ist es zum totlachen, wie sehr sich Entwickler einen abbrechen. Wenn Du Deutsch besser kannst, dann verwende Deutsch. Entwickelst Du für die Welt, dann eben Englisch (nachdem Du es fließend beherrscht).

2. Funktionen und GUI klar trennen.
Die Funktionalität packst Du in separate Units. Dabei fässt Du semantisch zusammenhängende Funktionalitäten zusammen. Wenn Du z.B. diverse Funktionen für einen 'Kunden'-Datensatz hast, dann kommen die in eine Unit 'uKunden.Pas' (oder so ähnlich)

3. Objektbezogene Funktionalitäten in Klassen zusammenfassen
Nachdem Du deine ganzen Funktionen und Prozeduren klassifiziert hast, kannst Du dir einzelne Klassen daraus basteln.

4. Verwende Patterns
Besorg Dir ein gutes Buch über Musterorientiertes Softwaredesign und verstehe, wie einfach man sich damit das Leben machen kann. Finde in deinem Code Passagen, die man über die bekannten Grundmuster (GoF) abbilden kann und wende sie an.

5. Sei Faul
Schreibe für jede Funktionalität genau eine Routine. Vermeide Codewiederholungen. Sobald ein nicht total triviales Codefragment mehr als einmal in deinem Projekt auftaucht, schreibe eine eigene Routine dafür (Wiederverwendbarkeit).

Natürlich kann man noch die eine oder andere Refactoring-Regel anwenden, für Wiederverwendbarkeit sorgen, Code unabhängig gestalten, etc. etc. etc.

Beim nächsten Projekt hälst Du dich noch an folgende Regeln:
1. Keep it simple. Lieber einen klaren, als einen schnellen Weg wählen (außer bei echt zeitkritischen Prozessen)
2. Make it readable. Programiere so, das jemand anderes deinen Code versteht, und Dir auf die Schulter klopfen würde.
3. Comment your code in the Sprache, die Dir am besten zusagt. Wozu umständlich in Englisch formulieren, wenn Du Deutsch viel besser kannst...

Schreibe deinen Code immer so, das er lesbar, klar strukturiert und leicht verständlich ist. Kommentiere kniffelige Tricks. Unterfordere den Leser nicht mit Kommentaren à la 'Zählvariable um eins erhöhen'.

Guter Code ist wirklich selbstdokumentierend. Verwende z.B. lokale Prozeduren / Funktionen, um kleine Teilaufgaben ('Finde kleinsten Wert') im Code zu dokumentieren.
Statt:

Delphi-Quellcode:

Var
  iMin, i : Integer;

Begin
 // Hier ist Code
 ...
  iMin := MaxInt;
  For i:=0 to lListe.Count - 1 do
    If lListe[i]<iMin Then iMin := lListe[i];
 // Noch mehr Code

vielleicht sowas hier:

Delphi-Quellcode:

Var
  iMin : Integer;

  Function _FindeKleinstenWert;
  Var
    i : Integer;

  Begin
    Result := MaxInt;
    For i:=0 to lListe.Count - 1 do
      If lListe[i]<Result Then Result := lListe[i];
  End;

Begin
  // Hier ist Code
  ...
  iMin := _FindeKleinstenWert;
  ...

u.s.w.

Es ist noch kein (Programmier)-Meister vom Himmel gefallen denn erst die Übung macht den Meister.

Und last, but not least: Verwende UML und OOP erst dann, wenn Du es kannst. Vorher bringt das nix. Im Übrigen denke ich nicht, das man mit UML automatisch tolle Programme hinbekommt. Man hat sein Chaos nur besser dokumentiert (sprich: grafisch dargestellt). Designfehler bekommt man damit auch nicht weg.

[Phoenix]

Ein weiteres Stichwort, was Dir helfen könnte passende Artikel (und Bücher) zu finden, sind 'Patterns'.
Patterns sind genau das, was sie auch übersetzt sind: Schablonen - oder auch Blaupausen. Also Vorlagen an immer wieder benutzbaren Code-Konstrukten (Rohbauten / Grundgerüste) für immer wiederkehrende Aufgabenstellungen.

Für die schon angesprochene Trennung von GUI und (Business-)Logik gibt es z.B. das Model-View-Controller Pattern (kurz MVC) oder aber auch das Model-View-ViewModel - Pattern (MVVM).

Wenn Du in der Richtung mal nach Artikeln im Netz suchst und Dir ein gutes Buch zu Patterns zulegst und das durcharbeitest kannst Du Dir damit die Erfahrungen von vielen schlauen Entwicklern und Software-Architekten zu eigen machen. Die haben das Rad ja alle schonmal erfunden, und die Räder von denen erfüllen immer ihren Zweck. Da kann man die auch selber weiterbenutzen

[Pfoto]

Hallo taaktaak!

mir geht / ging es ähnlich,
ich bin auch kein studierter Informatiker, versuche aber
mein gesetztes Ziel (ein kleines Programm das tut was ich geplant habe )
möglichst "professionell" zu programmieren...

Auf diesem Wege habe ich auch schon mehrere Anläufe hinter mir,
da ich ständig dazulerne, wie man es besser machen könnte.
Der Weg ist also bei mir das Ziel könnte man sagen.


Die schon erwähnten Patterns haben mir auch geholfen,
besonders dieses Buch hier, auch wenn es für JAVA ist:
"Entwurfsmuster von Kopf bis Fuß" vom O'Reilly Verlag
(ISBN-13: 978-3897214217)

Zudem gibt es auch noch einige im Internet übersetzt für Delphi.


Einer meiner Anfänger-Fehler war z.B., dass ich bestimmte
Funktionalitäten in eine große Prozedur gepackt hatte und
zusätzlich darin auch noch Bezug zu den Controls des GUI
meines Programms hatte.
Das sowas auf Dauer unnötige Fehler produziert, da man dort
nicht mehr durchblickt, ist klar... und es machte mir auch
keinen Spaß mehr in so einem Durcheinander weiter zumachen.


Nun gehe ich persönlich so vor:

- Ich habe einen Globalen Ordner, in dem alle wiederverwendbaren
Units liegen

- Möchte ich etwas programmieren, was ich vielleicht wiederverwenden
könnte, versuche ich es als autonome Klasse anzulegen.
Bezüge auf die GUI gibt es dann nicht mehr, sondern die Klasse gibt
Events ab, auf die ich in der GUI individuell Reagieren kann.

- Ich habe mein Programm modular mit Hilfe von PlugIns aufgebaut
(Tutorials und Hilfe gibts dazu auch hier im Forum)
Es ist auf Dauer einfach sehr übersichtlich, sich nicht durch
hunderte Formulare in einer einzigen Anwendung wühlen zu müssen,
sondern kann stattdessen gezielt Funktionalitäten mit Hilfe des
PlugIns hinzufügen.

- Und natürlich immer wieder nach neuem Wissen suchen, um
feststellen, wie unfähig ja man eigentlich noch ist...


Edit: Link durch ISBN ersetzt.

Gruß
Pfoto