Hallo,

ich möchte in den Sommerfieren jetzt ein größeres Projekt entwickeln. Das ansich ist nicht so das Problem, aber ich möchte es gleich so machen, dass es später leicht erweiterbar ist etc. Von daher die Frage: Wie entwicklen man professionell Software?
Also in wie große Teile zerlegt man Module? Bsp. aktueller Benutzer (untre PHP typisch): Rechte und Session in das User-Modul direkt rein, oder als Submodule, auch wenn die nur 100 Zeilen wären?
Wie die Module mit der GUI kommunizieren lassen? Direkt darauf zugreifen lassen, oder nur verarbeiten und die Ergebnisse gibt die GUI dann selber aus?
Bei letzteren habe ich jetzt den Fall, das ich nicht weiß, wie es am günstigsten wäre (aus diesem Grund habe ich auch den Thread hier eröffnet ): Ich habe ein Panel, wo man Benutzerdaten ändern kann. Es gibt aber 2 verschiedene Listen, wo man den Nutzer auswählen kann und wo Daten angepasst werden müssten. Wie würde man hier am besten rangehen?
Das Problem was ich habe ist, dass die Units sich überkreuzen würden, was Delphi ja nicht zulässt (das Mdoul bräuchte ne öffentliche var, aber gleichzeitig will das Modul auf die öffentliche Form-Klasse zugreifen).

Und was gibt es bei prof. Softwareentwicklung noch zu beachten? Eingebaut habe ich schon eine Unit für Konstanten (also im Prinzip wie ne CSS-Datei, nur das die reinkompiliert wurd) und eine Unit für Lang-Dateien, damit es einheitlich ist (wenn 5 Buttons die gleiche Caption haben, kann ich sie so gleich mit einem Schlag ändern).

Grüße
Heiko

CVS oder etwas Ähnliches solltest du auch verwenden
de.wikipedia.org/wik...rent_Versions_System

Hi Heiko,

Erstmal: Es gibt keine 'professionelle' Softwareentwicklung. Nur gute und schlechte. Du willst bestimmt gute SW erstellen. Ich weiss nicht, ob meine SW gut ist.

Also ich würde die einzelnen Klassen immer so entwickeln, das keiner sie 'hacken' d.h. zum Absturz bringen kann. Natürlich kann man jede Insantz zum abschmieren bringen, wenn man will, aber wenn Du genau definierst, wie deine input und output-Parameter strukturiert sein müssen ('Design by Contract'), dann ist das schon mal was. Innerhalb dieser Grenzen sollten deine Methoden absolut sauber arbeiten. Scheue dich nicht, eine Exception zu schmeissen, wenn irgend etwas faul ist.

Weiterhin würde ich mir über 'Qualität' im weitesten Sinne Gedanken machen. Qualität in der SW bedeutet: Dein Code/Klasse muss

-lesbar
-einfach
-wiederverwendbar
-robust (folgt zwangsläufig)

sein. Überlege Dir bei jeder Klasse einfach, das Du sie den Forumsmitgliedern zeigen musst ('Code Review') und verticken willst. Mit diesem Hintergrund baust Du automatisch ordendliche Klassen. Aber das weisst Du ja sowieso.

Darstellung (GUI) und Funktionalität (Objekte) solltest Du klar trennen. Im Idealfall repräsentiert ein Dialog eine Klasse und jeder Button eine bestimmte Methode der Klasse oder eine Verfeinerung des Dialogs (z.B. ein Button 'Details bearbeiten').

Klassenfunktionalität hat in Dialog-Modulen nichts zu suchen.

Auf datensensitive Steuerelemente würde ich verzichten. Sie eignen sich für kleine, einfache Frickeltools oder eben für RAD-Prototyping (dafür wurde Delphi ja ursprünglich entwickelt). Ich verwende sie, um Stammdaten zu pflegen. In meinen Projekten gibt es immer ein 'Control Center', das die grundlegenden Tabellen (Lookuplisten. Spracheinstellungen etc.) zum Bearbeiten bereitstellt. Na ja, aber sonst eben nicht.

Hmmm. Sonst noch was? Bestimmt, aber Du stellst so viele Fragen, das mir schon der Kopf schwirrt.

Strukturier das doch etwas (für so alte Säcke wie mich)

Aber Dein Vorsatz ist schon mal echt

hm

@alzaimar, warum keine db-sensitiven Steuerelemente?

Ich hader da immer mit mir, einerseits seh ich in der Praxis, daß sie mir Kontrolle nehmen...obwohl diesbezüglich hab ich devexpress fast fest im Griff

Allerdings, die Form, wie ich dann manche Kompos einstellen muß, um bestimmte Ereignisse zu bekommen, ist
schon wieder *igitt. Wie gesagt das Event-Handling mag ich da nicht besonders.

Nur bezweifel ich, daß es mir mit einem DevExpress StringGrid wesentlich besser gehen würde.

Gruß

Aga

Guck Dir mal hier die beiden Softwareentwicklungstuts an (ziemlich weit unten auffer Seite).

alzaimar hat folgendes geschrieben:

Erstmal: Es gibt keine 'professionelle' Softwareentwicklung. Nur gute und schlechte.

So ein Unsinn.
1. Professionelle Softwareentwicklung ist erstmal nur die Softwareentwicklung, mit der Geld verdient werden soll- daher professionell, was von profession = Beruf kommt
2. Es wäre wirklich wunderbar, wenn es nur gute und nur schlechte Softwareentwicklung gäbe. Denn dann könnte man genau sagen : das ist gut und das ist schlecht. So hätte man schnell die schlechten Arten aussortiert und die Welt wäre ideal.
Also nein, es gibt natürlich auch Grauzonen. Letzendlich gibt es kein Allheilmittel. Manche Prozesse und Vorgehensmodelle sind für einige Aufgaben nahezu Ideal, wobei es auch Aufgaben gibt, die sie sehr schlecht aussehen lassen.

Nun zur Softwareentwicklung:
Erstmal wird unter Softwareentwicklung nicht nur die reine Programmierung angesehen. Nein, das macht nur einen relativ geringen Teil aus. Zuvor kommt die Analyse, Spezifikationsdokument, Entwurfsdokument. Erst dann kommt die Implementierung. Danach und dazwischen sind die systematische Tests dabei. Danach kommt noch die Integration und Abnahme (+Tests).

So, ich hatte jetzt mal genug Zeit die Tuts von Sidorion durchzulesen (von dort habe ich schon ne Menge Tuts gelsen, aber eben nicht alle (und einige auch vergessen scheinbar )).

Coder hat folgendes geschrieben:

CVS oder etwas Ähnliches solltest du auch verwenden de.wikipedia.org/wik...rent_Versions_System

SVN werde ich für das Projekt wahrscheinlich noch nicht nehmen, da ich bisher die Erfahrung gemacht habe, dass man normalerweise nicht rückwärts geht. Ich benutze SVN nur, wenn es ein Projekt ist, wo mehrere daran arbeiten bzw wenn es ein php-Projekt ist, wo ich dann nur die Dateien hochlade, die sich wirklich verändert haben und ich somit keine Datei übersehe (handhabe ich beim phpBB-AbiForum von mir so )

alzaimar hat folgendes geschrieben:

Erstmal: Es gibt keine 'professionelle' Softwareentwicklung. Nur gute und schlechte. Du willst bestimmt gute SW erstellen. Ich weiss nicht, ob meine SW gut ist.

Dezipaitor hat folgendes geschrieben:

alzaimar hat folgendes geschrieben: Erstmal: Es gibt keine 'professionelle' Softwareentwicklung. Nur gute und schlechte. So ein Unsinn. 1. Professionelle Softwareentwicklung ist erstmal nur die Softwareentwicklung, mit der Geld verdient werden soll- daher professionell, was von profession = Beruf kommt 2. Es wäre wirklich wunderbar, wenn es nur gute und nur schlechte Softwareentwicklung gäbe. Denn dann könnte man genau sagen : das ist gut und das ist schlecht. So hätte man schnell die schlechten Arten aussortiert und die Welt wäre ideal. Also nein, es gibt natürlich auch Grauzonen. Letzendlich gibt es kein Allheilmittel. Manche Prozesse und Vorgehensmodelle sind für einige Aufgaben nahezu Ideal, wobei es auch Aufgaben gibt, die sie sehr schlecht aussehen lassen.

Ich sehe es als Mischung aus beidem .
professionelle Softwareentwicklung ist bei die Softwareentwicklung, bei der selbst große Projekte (ein paar tausend Zeilen und Klassen) man die Übersicht über den Code noch behält und ihn leicht verstehen kann. Das ist meistens zwangsläufig bei Beruflern so, und auch bei einigen FreewareEntwicklern, aber leider nicht viel. Von daher stimme ich hier beiden zu .

Dezipaitor hat folgendes geschrieben:

Nun zur Softwareentwicklung: Erstmal wird unter Softwareentwicklung nicht nur die reine Programmierung angesehen. Nein, das macht nur einen relativ geringen Teil aus. Zuvor kommt die Analyse, Spezifikationsdokument, Entwurfsdokument. Erst dann kommt die Implementierung. Danach und dazwischen sind die systematische Tests dabei. Danach kommt noch die Integration und Abnahme (+Tests).

Ja, dieser Ablauf ist mir bekannt (hatten wir schon oft genug im InfoLK). Als Analyse und Spezifikationsdokument diente bei mir eine Exel-Tabelle, wo ich bisher das praktiziert habe, was ich als nächstes per Software machen möchte (nur wesentlich benutzerfreundlicher und funktionsumfangsreicher (mehr Statistiken etc.)).

alzaimar hat folgendes geschrieben:

Also ich würde die einzelnen Klassen immer so entwickeln, das keiner sie 'hacken' d.h. zum Absturz bringen kann. Natürlich kann man jede Insantz zum abschmieren bringen, wenn man will, aber wenn Du genau definierst, wie deine input und output-Parameter strukturiert sein müssen ('Design by Contract'), dann ist das schon mal was. Innerhalb dieser Grenzen sollten deine Methoden absolut sauber arbeiten. Scheue dich nicht, eine Exception zu schmeissen, wenn irgend etwas faul ist.

Von Exceptions direkt halte ich nicht viel. Ich verhindere lieber gleich im Ansatz den Fehler oder gebe ihn über normale Meldungen aus. Also das Meldungen nicht vom Core geschmissen werden, sondern von der GUI (ich hasse try-Blöcke )

alzaimar hat folgendes geschrieben:

Weiterhin würde ich mir über 'Qualität' im weitesten Sinne Gedanken machen. Qualität in der SW bedeutet: Dein Code/Klasse muss -lesbar -einfach -wiederverwendbar -robust (folgt zwangsläufig) sein. Überlege Dir bei jeder Klasse einfach, das Du sie den Forumsmitgliedern zeigen musst ('Code Review') und verticken willst. Mit diesem Hintergrund baust Du automatisch ordendliche Klassen. Aber das weisst Du ja sowieso.

Das ist das Hauptziel bei mir. Das lesbar ist dabei das schwierigste (ich nehme immer zu wenige Kommentare). Wir hatten im Praktikum mal nen kleinen CodeReiew gemacht. Das Problem war da nur, dass die anderen die Sprache nicht so gut beherrschten und dadurch nicht immer verstanden, was ich gemacht habe (viel mit Zeigern).

alzaimar hat folgendes geschrieben:

Darstellung (GUI) und Funktionalität (Objekte) solltest Du klar trennen. Im Idealfall repräsentiert ein Dialog eine Klasse und jeder Button eine bestimmte Methode der Klasse oder eine Verfeinerung des Dialogs (z.B. ein Button 'Details bearbeiten').

Das ist das Hauptanliegen von diesem Thread - wie man das am günstigsten macht.

Klassenfunktionalität hat in Dialog-Modulen nichts zu suchen.

alzaimar hat folgendes geschrieben:

Auf datensensitive Steuerelemente würde ich verzichten. Sie eignen sich für kleine, einfache Frickeltools oder eben für RAD-Prototyping (dafür wurde Delphi ja ursprünglich entwickelt). Ich verwende sie, um Stammdaten zu pflegen. In meinen Projekten gibt es immer ein 'Control Center', das die grundlegenden Tabellen (Lookuplisten. Spracheinstellungen etc.) zum Bearbeiten bereitstellt. Na ja, aber sonst eben nicht.

Ich mahcs allgemein so, dass das meiste bei den GUI-Objekten liegt, denn VirtualStringTree verleitet einen regelrecht dazu. Allerdings will ich versuchen es doch so zu machen, dass einen Core gibt, der ohne dem klar kommt. Ich hoffe das geht bei meinem Projekt .

alzaimar hat folgendes geschrieben:

Aber Dein Vorsatz ist schon mal echt

Wenn man irgendwann Info studieren möchte, sollte man sich so etwas nun einmal so schnell wie möglich angewöhnen .



So nun zu der offenen Frage. Kleine (ungefragt) Fragen wurden ja von den Tuts mitbeantwortet. Übrig geblieben ist:

• Wieviele Klassen tut man in eine Unit (also was ist eurer Erfahrung nach das Optimum vom Umfang her)
  
• Wie kann man Delphi dazu bringen das 2 Klassen die in verschiedenen Units nicht zirkulaär miteinander kommunizieren können?

Beim letzten Punkt wäre folgendes Beispiel:





Oder muss zwangsläufig alles Gui-mäßige in die Hauptklasse?

Grüße
Heiko

Heiko hat folgendes geschrieben:

[*]Wieviele Klassen tut man in eine Unit (also was ist eurer Erfahrung nach das Optimum vom Umfang her)

Ich würde das so gliedern, dass es Sinn macht. Also grundsätzlich ein Modul, also eine thematische Einheit in eine Unit, solange es Sinn macht und lesbar ist. Wenn die Unit zu groß wird, kann man das Modul ja auch auf mehrere Units verteilen

Gruß
alias5000

Also ich würdwe zur Übung mit was kleinem anfangen, um ein Gefühl für das OOP-Denken zu bekommen. Dann merkt man ziemlich schnell, dass die Hauptarbeit im Kopf passiert, beim entwicklen und Zusammenspiel der Klassen. Ds dann zu programmieren, ist dann nur noch reine Fleißarbeit an der Tastatur.

Gerade gestern hatten wir einen ähnlichen Fall in der Delphipraxis: www.delphipraxis.net...unterklasse+aus.html daraus ist dann meine Lösung für das Problem entstanden: www.delphipraxis.net...50_memory+spiel.html
Lies dir vorallem mal mein eigenes Zitat aus dem zweiten Link durch. Dann wirst du sehen, dass sich der Rest fast von alleine ergibt.

So wie du es dort machst habe ich auch vor - für das Core. Mein Problem hat nur etwas mit meinem allgemeinen Programmierstil zu tun.
Und zwar lagere ich den Code vom Forumlar meistens in extra Klassen aus, damit es übersichtliger ist. Denn bei den Kompos bekommt man noch haufen Parameter mit, die ich nicht brauche. Von daher habe ich mir angewöhnt das auszulagern und nur das wichtige zu übergeben. Ohne dieser Eigenart sehe ich da kein Problem, aber ich mag nun einmal nicht die fertigen Parameter von Borland .

Ist vielleich nicht der gewöhnlichste Programmierstil
Aber wenn du diese Klassen noch rein zur GUI packst, dann sollte ne Core/GUI Trennung ja möglich sein (aber welche Funktionen haben dann diese Klassen? )

Gruß
alias5000

*grumel* so langsam verzweifle ich an Delphi (vlt. liegts auch daran, dass man das Problem bei PHP nicht kennt ). Ich habe in einer Unit nen GUIManager und in einer anderen Unit den UserManager. Aber wegen dieser sch**** Überkreuzung funzt das nicht. Und ich will nicht alles in eine Unit packen, weil die sonst paar tausend Zeilen hätte... Gibts da keine schöne Variante?

@Luckie: Wie du es bei deinem Proggi gemacht hast, kann ichs leider nicht. Denn die GUI soll nicht zur Laufzeit erzeugt werden .

Heiko hat folgendes geschrieben:

Ich habe in einer Unit nen GUIManager und in einer anderen Unit den UserManager. Aber wegen dieser sch**** Überkreuzung funzt das nicht. Und ich will nicht alles in eine Unit packen, weil die sonst paar tausend Zeilen hätte... Gibts da keine schöne Variante?

Neue Frage -> Neuer Thread

@Christian: Das ist ein Teil der Frage (siehe ersten Beitrag)

Dein Anfangsposting enthält wahrscheinlich zehn Fragen. Solange keine davon im Detail besprochen werden soll, sondern nur zur Verdeutlichung dient, worum es Dir geht - okay. Aber die Detailbesprechungen alle in einem Thread zu machen, ist nicht sinnvoll oder erwünscht.