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 :coder:
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) :cyclops:

Gruß Ralph

[freak4fun]

Zitat:

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:

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. :gruebel:

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. :D

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

MfG
freak

[Bernhard Geyer]

Zitat:

Zitat von freak4fun

Zitat:

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. :gruebel:

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:

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 ? :shock: 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 :-D )
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... :wink:


Edit: Link durch ISBN ersetzt.

Gruß
Pfoto

[taaktaak]

Hallo DP-Freunde :hi:

Ich möchte mich für die große Resonanz und die ja sehr ausführlichen Antworten bedanken. Ihr habt es richtig erkannt: Ich habe sehr lange prozedural programmiert und (wohl immer noch) gewissen Berührungs-Probleme mit OOP (obwohl das schon weniger wird). Ja, ich meinte tatsächlich Include-Dateien, wie wir sie noch aus den alten Turbo-Pascal-Zeiten kennen. Aber wie gesagt, diesen Irrweg habe ich auch schon wieder verlassen.

Das ganze ist sicher ein Entwicklungsprozess, der eine gewisse Zeit braucht. Ausserdem schreibt man ja als Hobby-Programmierer nicht ständig "größere" Programme. Werde mir die Anregungen von euch mal in Ruhe vornehmen und schauen, was davon in dem aktuellen Projekt sinnvoll noch zu ändern ist. Bevorzugt werde ich dabei wohl die Ratschläge "Funktionalität in separate Units packen" und "direkte Bezüge zur GUI in Funktionen/Prozeduren vermeiden" beherzigen.

Wenn das Programm "vorstellungsreif" ist, würde ich es hier gern einmal veröffentlichen. Dann wohl auch mit dem Source, auch wenn ich da im Augenblick ein wenig Hemmungen habe - aber vielleicht schaut sich das dann doch noch der eine oder andere an und wird konkrete Verbesserungsvorschläge machen.

Noch mal vielen, vielen Dank für die Antworten!
Gruß Ralph

[taaktaak]

Noch ein Nachsatz:
Habe jetzt den Thread gefunden, in dem das Thema vor einiger Zeit schon mal diskutiert wurde: Das von mir gesuchte Stichwort ist MVS :hello:
Gruß Ralph

PS: Hm, hab's nicht geschafft in diesen Text einen Link zu dem Thread einzufügen - wie macht man das???

[Pfoto]

Zitat:

Zitat von taaktaak

PS: Hm, hab's nicht geschafft in diesen Text einen Link zu dem Thread einzufügen - wie macht man das???

Du kannst einfach die URL kopieren und mit der Taste "URL" über dem Beitrags-Editor
diese einfügen.

Gruß
Pfoto

[taaktaak]

Joooo, nun habe ich's begriffen...
Hier wurden zu diesem Thema also auch schon Hilfen gegeben: Viele Prozeduren auf Form auslagern
Danke und Gruß von Ralph

[grenzgaenger]

hätte da noch eine anmerkung, zu alzaimar fast kompletten aufsatz :-) . verwende regions (code folding) zur aufteilung des codes, das erhöht die übersichtlichkeit. benötigt aber einen etwas neueren compiler... :-)

[Hansa]

Habe mal bei mir geguckt. Die größten Units liegen bei 500 - 1000 Zeilen. Allerdings sind das vererbte Zeilen. D.h. der Großteil davon ist bereits vorher definiert. Sind tatsächlich für ein einziges Formular 5000 Zeilen vorhanden :shock: , dann muss das unbedingt aufgeteilt werden ! Egal, was Alzaimer sagt. :mrgreen: Und weils so schön ist : was sind Patterns, bzw. wozu soll so was gut sein ? :shock:

[Phoenix]

Zitat:

Zitat von grenzgaenger

hätte da noch eine anmerkung, zu alzaimar fast kompletten aufsatz :-) . verwende regions (code folding) zur aufteilung des codes, das erhöht die übersichtlichkeit. benötigt aber einen etwas neueren compiler... :-)

Schwachfug. Was hat ein Compiler mit Regions zu tun? Das ist ausschliesslich Sache der IDE...

[Phoenix]

Zitat:

Zitat von Hansa

Und weils so schön ist : was sind Patterns, bzw. wozu soll so was gut sein ? :shock:

Hansa, Du schockst mich.
Was Patterns sind habe ich schon kurz erwähnt. Das sind Schablonen bzw. Codevorlagen / Codebeispiele für immer wiederkehrende Aufgabenstellungen.

Es gibt Patterns für Singletons, es gibt das Observer-Pattern (wenn ein Objekt beobachtet / kontrolliert werden muss), es gibt für ungeheuer viele Konstellationen fertige Patterns. Auch ganz Nett ist z.B. insbesondere der Decorator für die Delphi-Komponentenentwicklung (siehe z.B. Decorator - Pattern).

Wozu die gut sind?

Nunja: Wenn ich einen Singleton implementieren muss nehme ich das Pattern her, und überlege mir keine eigene Implementation. Hintergrund: Der Code des Patterns in durchgetestet und tausendfach im Einsatz. Wenn ich's selber mache könnte ich einen Fehler implementieren. Den erspare ich mir so.

Ergo: Zeitersparnis (Lösung selber ausdenken und implementieren und eigene Lösung testen entfällt alles) UND Qualitätszuwachs (bereits bewährter Code, der schon zigfach gezeigt hat das er funktioniert) in einem.

[alzaimar]

Zitat:

Zitat von Hansa

Habe mal bei mir geguckt. Die größten Units liegen bei 500 - 1000 Zeilen. ...Egal, was Alzaimer sagt. :mrgreen:

So sollte das sein.

Zitat:

Zitat von Hansa

Und weils so schön ist: was sind Patterns, bzw. wozu soll so was gut sein ? :shock:

Gute Frage. Nachdem ich mich dann doch auch mal damit beschäftigt habe, kann ich Dir das ziemlich genau erklären: Patterns sind Programmiertricks, die man die ganze Zeit schon benutzt hat, aber durch die Arbeiten der GoF (u.A.) nun endlich einen Namen bekommen haben. :mrgreen:

Im Ernst: Patterns bringen viele programmtechnische Kniffe auf den Punkt, die man sich über die Jahre selbst erarbeitet hat, bieten dabei aber immer noch die eine oder andere Überraschung.

Patterns sind kodierevolutionstechnisch ( :wiejetzt: ) gesehen ein Meilenstein und der Endpunkt der 3.Phase der Programmiertechnik. Die erste Phase waren von Basic, Cobol und Fortran beherrscht, die zweite Phase durch strukturierte Programmierung und die dritte Phase wurde durch die Einführung von OOP geprägt. Der damit einhergehende Wildwuchs wurde imho durch die Manifestierung in Entwurfsmuster erst in geordnete Bahnen gelenkt. Man programmiert nun nicht mehr auf Zeilenebene, sondern ein, zwei Stufen höher und läst die dabei entstehenden Muster von Codern ausformulieren.

Hansa, es schadet nicht, sich das mal reinzuziehen. Das meiste kennst Du und wirst das sowieso schon so machen, aber wenigstens kannst Du dann mitreden :mrgreen:

[MarcoWarm]

Zitat:

Zitat von Phoenix

Schwachfug. Was hat ein Compiler mit Regions zu tun? Das ist ausschliesslich Sache der IDE...

da hast du leider unrecht Phoenix. Die IDE ist zwar gänzlich für die Anzeige (Codefolding) einer Region verantwortlich. Ein älterer Compiler hingegen kann Code mit Regions nicht erzeugen. Das liegt daran, daß eine Region mit {$ beginnt. Ein Delphi 7 würde versuchen das als Compilerdirektive zu werten.
Just my 2 cents.

[franktron]

Ich hätte da gerne mal ein Beispiel.

Also wir haben eine DB Programm.

1. DBGrid ein paar Edit Felder (für Eingabe).

So jetzt kann ich die Eingabe und Lese Routinen für die Edit Felder in eine Andere Klasse legen aber wie die DBGrid ???

[Phoenix]

Also GUI <> Daten-Entzerrung?

Im Prinzip gehört die Steuerung der Controls aufs Formular.
Nur die Zugriffe auf die Daten (also erstellen und Verwalten des DataSets, Operationen auf den Daten etc.), das gehört in eine andere Klasse.

Dazwischen setzt Du einen Controller (nochmals eine Klasse), der die Datenklasse und das Formular kennt, und dann das ganze miteinander verdrahtet (also Dataset and Controls / Grid hängen etc).

[franktron]

Zitat:

Zitat von Phoenix

Also GUI <> Daten-Entzerrung?

Im Prinzip gehört die Steuerung der Controls aufs Formular.
Nur die Zugriffe auf die Daten (also erstellen und Verwalten des DataSets, Operationen auf den Daten etc.), das gehört in eine andere Klasse.

Dazwischen setzt Du einen Controller (nochmals eine Klasse), der die Datenklasse und das Formular kennt, und dann das ganze miteinander verdrahtet (also Dataset and Controls / Grid hängen etc).

Ja und wie ich hab da gar keine idee. :?:

[alzaimar]

Es ist doch ganz einfach:

Jeder Löffel (=Aktion, Prozedur) gehört in den Topf (=Unit bzw. Klasse), in dem er rühren soll.

Die Kontrolle, wie sich die GUI verhält (Knöpfe aktivieren, wenn Daten verändert wurden etc.), gehört nunmal in die Formularklasse, aber was dann mit den Daten passiert, in die Datenklasse.

Aber wir wären ja schön blöd, wenn wir das konsequent und ohne Rücksicht auf Verluste jedesmal durchziehen würden. Also gibt es natürlich Ausnahmen. Die bleiben aber wirklich Ausnahmen.

Andererseits macht man sich später mehr Arbeit, die Funktionalität dann doch auszulagern.

Beispiel: Wir basteln uns einen Logindialog.

Wir fangen an mit zwei Eingabefeldern, OK- und Abbruch-Knopf. Bei OK wird kurz in einer Tabelle nach dem User und dem Passwort gefragt und im Modal entweder mrOK, mrCancel oder mrNo zurückgeliefert (egal jetzt, ob das so toll ist).

Drei Zeilen Logik. Und dafür ne Klasse? Quatsch mit Soße!

Oh, nun soll das Passwort doch verschlüsselt abgelegt werden. Na und, suchen wir halt nach dem verschlüsselten Passwort. Wupps, eben eingebaut. Fertig.

Oh, nun sollen noch Benutzerrechte eingelesen werden. Oh, hmm. Egal, reingebepselt. Fettig.

Spätestens jetzt darf man ordendlich in die Team-Kaffekasse zahlen, weil man zu frickeln anfängt und anderen das Leben schwermacht. Als Strafarbeit muss man nun den Code nochmals entwirren und allen Beteiligten zusätzlich einen ausgeben.

Also dann doch lieber gleich von Anfang an eine TBenutzer- und vielleicht eine TBenutzerlist-Klasse in einer separate Unit 'uBenutzerverwaltung', und schon ist das ordendlich entkoppelt. Die TBenutzerliste hat dann eben nur eine Methode 'PrüfeBenutzerLogin', und die besteht aus drei Zeilen. Der TBenutzer kommt gänzlich ohne Logik aus. Na und?

Jemand kann sich am Login-Dialog blöd designen (dass das nicht so schwer ist, sieht man an den ganzen grenzdebilen Designern :mrgreen:), und die Coderecke kann sich an der Benutzerverwaltung unter Vermeidung von natürlichem Licht einen Wolf programmieren (Benutzergruppen, Zugriffsrechte, sichere Passwörter, automatisch ablaufende Passwörter, Backdoors, yippie!)

[franktron]

Das ist mir schon klar ist auch nicht das Problem,
aber wie mach ich das wenn die Design-Schicht DB Kombos nutzt (also DBGrid) dann muss ich ja im Design eine DB Abfrage machen wie kann man das über die DB Schicht machen, oder lohnt das nicht.

Um meine Fragen zu begründen, ich muss demnächst eine Software Komplett neu schreiben und will das gleicher vernünftig machen.

[Phoenix]

Hrm. Dilemma, Dilemma.

'Ordentliches' Anwendungsdesign hat mit RAD in unserem Sinne nicht viel Gemeinsam. Du schmeisst zwar noch die Grid auf das Form, aber mit den Daten verbinden, die Daten in den Fachklassen selektieren, bearbeiten etc., das passiert in der Regel alles im Code.

Für so eine Datenschicht gibts nunmal keinen Designer (ob Leider oder zum Glück sei mal dahingestellt).

[franktron]

Also um das mal einfach zu sagen.

1 Form (Design)
1 DatenModule mit DB Klasse wo dann auch die DBGrid angedockt wird. ?

[alzaimar]

Zitat:

Zitat von Phoenix

'Ordentliches' Anwendungsdesign hat mit RAD in unserem Sinne nicht viel Gemeinsam.

Einspruch: Das beste Werkzeug verkommt zum Faustkeil, wenn man es nicht richtig anwendet.

RAD / Delphi bietet uns mit Datenmodulen doch eine Möglichkeit an, um GUI und Logik zu trennen. Datenmodule sind klassisch gesehen doch nur Datencontainer, um sich das ewige hin- und hertransportieren der Daten zu ersparen. Mit der Delphi-Toolleiste können wir derzeit 'nur' Tabellen, Imagelists etc. dort ablegen, um sie im Code gemeinsam zu nutzen. Nichts hindert uns, weitere Funktionen dort zu hinterlegen.

Und mit dem Modeldesigner haben wir auch noch eine erste Metapher, um Klassen visuell zu gestalten. Ob das effektiv ist, sei mal dahingestellt...

@franktron: Genau so. TDataset-Derivate gehören ins Datenmodul und *nicht* auf die Form. Die Logik der berechneten Felder hat doch im Formular nix zu suchen, oder?

[Dezipaitor]

Bei der heutigen Softwareherstellung sind die Werkzeuge das geringste Problem.
Die Probleme, die zur Aufgabe von SW-Projekten führen sind meist die nur schwer erfassbaren Faktoren, wie Teamfähigkeit und besonders Kommunikation.

Besonders die Kommunikation zwischen Auftraggeber und -nehmer ist das Problem. Hier laufen oftmals das Gewollte und das Erbrachte auseinander.

Dies gilt besonders für Projekte, die bereits mit der ganzen Kunst des Sofwareprojektmanagments überwacht werden.
Die meisten Projekte werden heutzutage jedoch immer noch ohne Dokumentation und Managment hergestellt. Ich spreche dabei jedoch nicht von Hobbyprojekten!

[Viktorii]

Hallo zusammen.

Zitat:

Zitat von Pfoto

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.

Das würde mich mal genauer interessieren. Könntest du dazu mal ein kurzen Beispielcode posten?

Vielen Dank

[Hansa]

Langsam wirds unübersichtlich, wohl wegen der Patterns. :mrgreen:

'Grosse Programme "übersichtlich" programmieren'

Für mich taucht folgende Frage auf : wer hat in seinen Programmen des öfteren in den Form-Deklarationen folgendes stehen

Delphi-Quellcode:

  TFormXY = class(TForm)

?? Interessiert natürlich nur, sofern das Programm mehr als eine Form hat, was bei größeren Programmen wohl kaum der Fall sein dürfte. Hier hat gerade einer behauptet, das wäre normal. Bin selber aber der Ansicht, dass so etwas Schwachsinn ist. :P

[alzaimar]

Zitat:

Zitat von Viktorii

Zitat:

Zitat von Pfoto

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.

Das würde mich mal genauer interessieren. Könntest du dazu mal ein kurzen Beispielcode posten?

Z.B. TDataSource.OnDataChanged

Zitat:

Zitat von Hansa

Langsam wirds unübersichtlich, wohl wegen der Patterns. :mrgreen:

Nee, eher weil sie nicht eingesetzt werden. Wir haben hier ein Kuddelmuddel aus Meinungen zum Thema oder auch nicht. Ein Entwurfsmuster à la 'Beim Thema Bleiben Oder neuen Thread mit Link aufmachen' würde eine perfekte Übersichtlichkeit herstellen.

Zitat:

Zitat von Hansa

...wer hat in seinen Programmen des öfteren in den Form-Deklarationen folgendes stehen

Delphi-Quellcode:

  TFormXY = class(TForm)

?? Interessiert natürlich nur, sofern das Programm mehr als eine Form hat, was bei größeren Programmen wohl kaum der Fall sein dürfte. Hier hat gerade einer behauptet, das wäre normal. Bin selber aber der Ansicht, dass so etwas Schwachsinn ist. :P

Dein Problem bzw. wieso das Schwachsinn ist, verstehe ich nicht.

[Hansa]

Zitat:

Zitat von alzaimar

Dein Problem bzw. wieso das Schwachsinn ist, verstehe ich nicht.

Eben wegen der "Patterns". :stupid: Aber wieso Problem ? Gut, ich frage anders : wer hat Programmm mit > 5 Forms und da steht überall in den Units :

Delphi-Quellcode:

TFormXY = class(TForm)

Nennt das von mir aus "Meinungsumfrage". :mrgreen:

[Elvis]

Zitat:

Zitat von alzaimar

Einspruch: Das beste Werkzeug verkommt zum Faustkeil, wenn man es nicht richtig anwendet.

Ein Versuch RAD mit vernünftigem Code zu verbinden, war zum Beispiel SWF und WPF in .Net. Aber auch da ist einem der RAD-Teil eher im Weg, und erschwert es zügig eine wartbare anwendung zu bekommen.
RAD im Sinne von Delphis RAD (oder VBs) zielt auf reines Quick & Dirty und du würdest dich wundern wie viele Leute in Delphi 10 Jahre Erfahrung darin haben es falsch zu machen. (btw, JEDER VB'ler hat Jahre Erfahrung darin es furchtbar falsch zu machen)

Zitat:

Zitat von alzaimar

RAD / Delphi bietet uns mit Datenmodulen doch eine Möglichkeit an, um GUI und Logik zu trennen. Datenmodule sind klassisch gesehen doch nur Datencontainer, um sich das ewige hin- und hertransportieren der Daten zu ersparen. Mit der Delphi-Toolleiste können wir derzeit 'nur' Tabellen, Imagelists etc. dort ablegen, um sie im Code gemeinsam zu nutzen. Nichts hindert uns, weitere Funktionen dort zu hinterlegen.

DatenModule sind furchtbare Biester, die Entwicklern vormachen, sie würden ihre App strukturieren, wobei sie in Wirklichkeit worst-case-Pasta erzeugen...
Datenmodule funzen nur, wenn sie globale Variablen sind, und sie benötigen andere globale Variablen um deren Dingsens benutzen zu können.
OTOH, Delphis Designer machen alle Komponenten öffentlich sichtbar, von Kapselung also absolut keine Spur.

Ich muss dir hier also vehement widersprechen: DataModules sorgen für ein schreckliches Applikations design.
MVC, MVP oder irgendeine andere Form von Mediation zwischen Modell, Logik und Darstellung ist damit komplett für'n Arsch.
Alles was ohne Kapselung von außen geändert werden kann, kann dich nicht darüber informieren. Es ist nicht möglich ein elegantes Design mit solchem RADifiziertem Käse zu produzieren, das auch noch team-fähig ist.

Zitat:

@franktron: Genau so. TDataset-Derivate gehören ins Datenmodul und *nicht* auf die Form. Die Logik der berechneten Felder hat doch im Formular nix zu suchen, oder?

Das ist einer der Fehler, die gerne gemacht werden: Datenkrams auf einem DM macht es in keinster Weise besser wartbar als wenn man es gleich auf ein Form klatscht. Ist beides gleich ungeeignet, wenn man wartbare und partitionierbare Anwendungen bauen will.

[Phoenix]

Full Ack. Ich wollte nur nicht dermassen dagegen hauen.
RAD ist ganz sicher das perfekte Werkzeug, um mal kurz einen Prototypen hinzurotzen und um dem Kunden mal schnell was zu zeigen. Wenn man wartbare Anwendungen haben will, sollte man aber in Erwägung ziehen, lieber doch einiges von Hand und dafür richtig zu machen.

Denn sobald man sich ein wenig vom RAD-Weg entfernen muss, weil es eine Anforderung erfordert (und das passiert im echten Leben da draussen häufiger als man denkt), dann muss man sich sonst immer irgendwelche bösen Workarounds ausdenken. Sowas fällt weg, wenn man es gleich 'richtig' macht.

[alzaimar]

Ahoi Elvis,

Wo Du (bedingt) Recht hast (Datenmodule kapseln nichts), hast Du (bedingt) Recht. Natürlich ist das nicht die reine Lehre, aber die öffentlichen Komponenten sollen doch auch öffentlich sein und dienen der Interoperabilität mit den Formularen. Und die Geschäftslogik in Form der Ereignisse ist gekapselt. Der Designer bietet uns leider nicht die Möglichkeit, private Komponenten zu plazieren. Aber wenn das ginge, wäre das natürlich nett.

Das Datenmodule hingegen per se "furchtbare Biester" sind, "die Entwicklern vormachen, sie würden ihre App strukturieren, wobei sie in Wirklichkeit worst-case-Pasta erzeugen", sehe ich nicht. Es gilt immer: Wer's nicht kann, soll die Finger von den 'Biestern' lassen. Man muss sie auch bändigen können...

Bei den Möglichkeiten bzw. den Unmöglichkeiten, mit einer RAD automatisch gute Software zu erstellen, gebe ich Dir aber unbedingt Recht.

Aber wir sprechen von zwei paar Schuhen: Bei Systemen, die die, sagen wir 100.000 Codezeilen-Grenze durchbrechen, wird man sich hüten, mit Klick-und-Gut-Datenmodulen zu arbeiten. Das wäre ja wirklich Selbstmord. Da braucht es dann auch 90% der Komponenten nicht mehr und man sollte Delphi bzw. RAD (=Prototyping) wirklich nur für die GUI verwenden, wobei dann auch die GUI nicht mehr statisch sein dürfte und auch dann Delphi (und jede andere IDE) derzeit nicht in der Lage sein dürfte, die dynamischen Formulare zu unterstützen.

Bei Projekten zwischen 5.000 und 100.000 (nur Hausnummern) bietet RAD eine wirklich brauchbare Möglichkeit, Projekte in vertretbarer Zeit zu vernünftigen Preisen anzubieten, die dann (entsprechende Dispziplin vorausgesetzt) auch wartbar sind. Alles, was darüber hinaus geht, geht damit nicht mehr.

Bevor ich diesen Exkurs abschließe, möchte ich noch darauf hinweisen, das RAD imho eher RAP heißen sollte, also nicht Rapid Application Development, sondern einfach Rapid Prototyping. Und dann verbietet es sich ja, sich eine ordendliche Anwendung zusammen zu klicken...

[franktron]

So jetzt bin ich ganz durcheinander.

Wie macht man denn das heutzutage,
Wenn man mal ganz einfach ein ganz einfache Kundenverwaltungen machen will.

Also Grid für die Liste Neu Anlegen und Edit , Löschen u.s.w. ????

Wie sieht sowas den aus

[Elvis]

Zitat:

Zitat von franktron

So jetzt bin ich ganz durcheinander.
Wie macht man denn das heutzutage,
Wenn man mal ganz einfach ein ganz einfache Kundenverwaltungen machen will.

Die Frage ist immer, was ist einfach und vor allem: Ist es eine reine monolithische App, oder kann es sein, das sie sich zukünftig in ein bestehendes System integrieren müsste.
Natürlich kann es auch sein, dass es von verschiedenen Kunden verschiedene Anforderungen für Integrationen in ihre Systeme gibt.
Alles bis auf 1 ließe sich durch WebServices lösen, bei dem dein Client, also das hier:

Zitat:

Also Grid für die Liste Neu Anlegen und Edit , Löschen u.s.w. ????

Nur ein "Default client" wäre.
Der Kunde könnte den Webservice auch von innerhalb seiner in-House-Systeme aufrufen.
Entweder nur die Logik in einem Server, oder als mash-up im Client.

Software ist schon lange nicht mehr das, was sie mal war. Aber diese ganzen RADifizierten Apps sind komplett ungeeignet um ihre Logik und Prozesse in einem größeren System verwenden zu können.
"Größe" wäre hier nur die Anzahl an unterschiedlichen Diensten, nicht unbedingt die Anzahl der user. Auch kleine Firmen würden sowas bevorzugen, wenn es ihnen uralte Client/Server Apps nicht so schwer machen würden... ;-)


Und ganz btw: Eine Kundenverwaltung wäre auf jeden Fall etwas, dass ich in meine Prozesse integrieren können will. Und damit meine ich keine SOP á la "proprietären ERP client öffnen, xyz machen, Daten exportieren und per Hand in System Z einpflegen"

[grenzgaenger]

@phoenix: letzter post tja, ganz so ist es ja doch nicht. die regions stellen IMHO eine ganz brauchbare möglichkeit dar, um in den sourcecode (eine unit) ordnung zu bringen. wenn es über mehrere units geht, da müssen dann auch andere techniken her.

die DM's wurden ja damals von borland entwickelt, um den ruf der entwickler nachzukommen, die datenzugriffsroutinen zu zentralisieren. das geht ja damit auch... obgleich man die objekt ablage normal nicht braucht, wenn man das system nicht als drag-and-drop system sieht... sondern wenn man es ordentlich macht. und da brauchts das auch nicht mehr, da man die datenzugriffe auch wunderbar in eine eigene unit (oder auch mehrere) verpacken kann ... ich find es noch recht komfortabel, wenn alle tabellenhandlings in einer datei sind... da muss man nicht erst nach den ganzen units/formularen suchen... wo man jetzt ggf. noch 'n feld ändern muss oder noch irgendwelche persistenten felder...

@alzaimar: tja, prototyping, ist auch nicht so straight, da gibts ja auch unterschiedliche Philosophien... vom wegwerfen (von dir erwähnt) bis hin zum weiterentwickeln und zur marktreife zu bringen. wobei ich deinen ansatz (wegwerfen des prototypes) vorbehaltlos unterstütze... diese sind IMHO nur dafür da um designfragen mit dem kunden etwas realitätsnaher abzuklären... dafür taugt es, aber für mehr nicht.

nun noch 'n schönen abend
GG

[alzaimar]

Für eine Desktop-Datenbankanwendung ist das Model "Projekt = Datenmodul + Formulare" doch nun wirklich brauchbar.

Im C/S (Web)-Umfeld kommt man damit wirklich nicht weit, obwohl ich ein System basierend auf TSocketConnection seit 10 Jahren problemlos in einem 24/7-Umfeld und hunderten Erweiterungen in drei Fabriken im Einsatz habe. Aber man kann ja auch mit einem Faustkeil einen Baum fällen.

Ich wiederhole mich: Für kleine bis mittlere Anwendungen (einige wenige Mannmonate) reicht das o.g. Konzept (Datemodul+Formular) und RAD wirklich.
franktron,
Du kannst das System nun so konzipieren, das es auch für zukünftige Erweiterungen gerüstet ist. Dann solltest Du die Finger vom RAD-Ansatz lassen und gleich ordendliche Kunden-Klassen modellieren.

Oder Du willst jetzt eine Lösung, dann nimm ein Datenmodul, einige Formulare (Tipp: TDatasource auf die Formulare, denn vielleicht benötigst Du die Aktion 'Anwender wechselt im Grid den Datensatz') und datensensitive Komponenten (TDBEdit, TDBGrid) etc. Fertig.

Entwerfe die Dialoge so, das sie übersichtlich und intuitiv zu bedienen sind und vermeide Schnickschnack (Skins, coole Buttons etc.). Schließlich baust Du eine Kundenverwaltung und keinen Podcastplayer.