Entwickler-Ecke :: Thema anzeigen - Tipps für die Programmierung "großer" Anwendungen

0xDEAD - Mo 14.12.09 11:58
Titel: Tipps für die Programmierung "großer" Anwendungen

Hallo zusammen!

Folgendes liegt mir am persönlich mal sehr am Herzen.

Ich bin Softwareentwickler in einer kleinen Firma. Seit einem Jahr etwa bin ich hier angestellt und habe einige kleine Programme geschrieben.
Delphi kannte ich zwar, habe jedoch keine Erfahrung damit gehabt. Ich komme eigentlich aus der C/C++ Ecke.

Zur Zeit programmiere ich meine erste "große" Anwendung.
Mit Menüs, Popups, dynamischen Objekten und alles was eine ordentliche Anwendung so haben sollte.

Jetzt machen mir zwei Probleme das Leben schwer:

1) bin ich hier ziemlich auf mich allein gestellt. (ohne das DelphiForum etc. wäre aufgeschmissen. 1000 Dank!)

2) habe ich wenig Erfahrung mit großen Projekten

3) ist mir Delphi auch noch etwas fremd. Vor allem die prof. Funktionen und Möglichkeiten.

Ich suche jedenfalls Tipps wie ich meine Arbeit professioneller gestalten kann, wie ich mich besser in meinem Quellcode zurecht finde und wie ich sinnvoll große Projekte organisieren kann, auch in Verbindung mit den Möglichkeiten, die die Delphi IDE zur Verfügung stellt.
Vielleicht kennt auch jemand ein gutes Buch zu dem Thema oder einige Webseiten/Foren die als Anlaufstelle helfen können.
Ich habe auch schon einige OpenSource-Projekte gesucht, bei denen man sehen kann, wie andere Entwickler arbeiten, habe aber nur relativ kleine Projekte gefunden.

Vielleicht gibts ja auch hier schon einen Thread mit ähnlichem Thema, den ich nur nicht gefunden habe.

Schonmal danke für eure Hilfe!

0xDEAD - Mo 14.12.09 13:11

Das Grundwissen ist zweifellos da. Was ich suche ist eine Art "Best Practices" für Delphi.

Zur Zeit fühle ich mich etwas überfordert mich in meiner Anwendung zurecht zu finden, was zweifelsfrei daran liegt, dass es meine erste große Applikation ist.

Deshalb suche ich irgendwelche Ansätze wie man eine gut strukturierte Anwendung erstellt.

Klar, verweist man da schnell auf die allg. verwendbaren Entwurfsmuster. Aber die sind mir zu abstrakt und mir fehlt einfach die Zeit mich ausführlich damit zu beschäftigen, immer hin soll hier auch produktiv gearbeitet werden.

Trotzdem versuche ich so professionell wie möglich zu programmieren und gebe mich nicht damit ab, meine Programme so zu stricken, dass sie irgendwie laufen.

Vielleicht geht es ja mehreren hier so und wir können uns darüber etwas austauschen.

hansa - Mo 14.12.09 16:34

Das Stichwort OOP wird immer schnell in den Raum gestellt und ist auch richtig. Die Praxis sieht leider so aus, dass kaum einer das (zumindest nicht richtig) benutzt. Aber das ist auch ein vielschichtiges Thema. Ein wichtiger Ansatz ist IMHO dabei die "Objektablage" oder "Repository". Würde ich diese Technik nicht nutzen, dann wären meine Programme ca. um den Faktor 5-10 aufgebläht. Das Rad müsste immer wieder neu erfunden werden. Die Routinesachen werden so eben zentralisiert. Man stelle sich mal vor, bei 20 Forms jedesmal das OnKeyPress einzeln neu schreiben zu müssen oder gar C+P. Nene, das kommt bei mir in Formular inkl. Farben, Schriftgrößen etc. Von diesem werden dann andere abgeleitet. "Inherited;" lässt grüssen. Positiver Nebeneffekt : wichtige Änderungen sind an einer Stelle zu machen und nicht an 20 oder mehr.

Delphi-Hilfe hat folgendes geschrieben:

Die Objektablage

Die Objektablage stellt ein Hilfsmittel für die gemeinsame Benutzung und Wiederverwendung von Formularen und Projekten dar. Bei der Objektablage selbst handelt es sich einfach nur um eine Textdatei, die Verweise auf Formulare, Projekte und Experten enthält.

Gemeinsame Benutzung innerhalb mehrerer Projekte

Indem Sie der Objektablage Formulare, Dialogfenster und Datenmodule hinzufügen, machen Sie diese auch für andere Projekte verfügbar. In einem einfachen Beispiel könnten so alle Ihre Projekte dasselbe Textfeld Info über benutzen, das sie aus der Objektablage kopieren würden. Bei einer fortgeschritteneren Verwendung könnte es ein leeres Standard-Dialogfenster mit dem Firmen- oder Produktlogo und einer Standardanordnung der Schaltflächen geben, aus dem alle Ihre Projekte gleichaussehende Dialogfenster ableiten könnten.

Diese Möglichkeiten zur gemeinsamen Benutzung werden im einzelnen unter dem Punkt Die Optionen Kopieren, Vererben und Verwenden besprochen.

Gemeinsame Benutzung innerhalb eines Projekts

Die Objektablage kann Ihnen auch dabei helfen, einzelne Elemente innerhalb eines Projekts gemeinsam zu benutzen, indem es Ihnen ermöglicht wird, diese Elemente aus bereits im Projekt vorhandenen Formularen zu erben. Wenn Sie das Dialogfenster Neue Einträge öffnen (indem Sie Datei / Neu / Weitere wählen), sehen Sie eine Registerseite mit dem Namen Ihres Projekts. Diese Registerkarte enthält alle Formulare, Dialogfenster und Datenmodule Ihres Projekts. Sie können dann ein neues Element aus einem bereits bestehenden erstellen und es wie gewünscht anpassen.

Es könnte z.B. sein, dass Sie in einer Datenbankanwendung mehrere Formulare benötigen, die dieselben Daten anzeigen, die aber verschiedene Befehlsschaltflächen enthalten. Anstatt mehrere nahezu identische Formulare zu erstellen und zu pflegen, könnten Sie ein generisches Formular entwerfen, das alle Steuerelemente für die Datenanzeige enthält, und dann verschiedene Formulare erstellen, die den Entwurf für die Datenanzeige erben, aber unterschiedliche Befehlsschaltflächen besitzen.

Indem Sie die Formulare für Ihre Projekte sorgfältig planen, können Sie sich enorm viel Zeit und Mühe ersparen, indem Sie die Formulare innerhalb eines Projekts gemeinsam benutzen.

Gemeinsame Benutzung ganzer Projekte

Sie können auch ein ganzes Projekt als Muster für zukünftige Projekte zur Objektablage hinzufügen. Falls Sie z.B. eine Reihe ähnlicher Anwendungen entwickeln, kann Ihnen dabei ein einzelnes, standardisiertes Modell als Grundlage dienen.

Verwenden von Experten

Die Objektablage enthält außerdem Verweise auf Experten, bei denen es sich um kleine Anwendungen handelt, die den Benutzer durch eine Reihe von Dialogfenster für die Erstellung eines Formulars oder Projekts führen. Dazu werden verschiedene Experten zur Verfügung gestellt, Sie können aber auch Ihre eigenen hinzufügen.

catweasel - Mo 14.12.09 23:40

Hi,

Ich beschäftige mich jetzt schon ne ganze Weile mit Dephi (mit Unterbrechungen).
"grosse Projekte" gabs bei mir schon zu Basic Zeiten ;-)
Aber mal im Ernst: Noch nie hab ich grosse Projekte so einfach und schön schreiben können, als mit Delphi.

Ich weiss zwar nicht worum es bei deinem Projekt geht, aber wenn du etwas mehr erzählst was der Schwerpunkt ist? Grafische Oberfläche (CAD designer oder the next photoshop), wissenschaftlich (the next MatLab), wird es eine neuartige Datenbank mit kongenialer Abfragesprache?

Was ich mir bisher so an Projekten zusammengeschustert habe:
-eigener WebBrowswer (html parsen ist lustig)
-Assemblersprache für eigenen Kellerautomaten implementiert und einen (begrenzten) Compiler geschrieben.

... Gerade habe ich zwei Projekte am laufen:

- Ein Adventure Spiel im Stil von Under a killing moon (mit DirectX umgesetzt)
- Eine kleine Neuauflage einer relationalen Datenbank...DB2 lässt grüssen (herrliches low level file I/O und pointer spiele bis zum exzess).

Wenn irgendwas davon in deine Richtung geht, sag Bescheid :-)

Cheers,
Catweasel

Bergmann89 - Mo 14.12.09 23:56

Hey,

das besste (finde ich) is am Anfang erstma ne große Mindmap: Was soll mein Programm machen? Wievile Forms brauch ich? Was sollte/muss in eine extra Unit? Wenn mann dann den ganzen Umfang des Projektes in der Mindmap hat macht man ne 2. Mindmap, in der man die Klassen die man braucht im Baumdiagram darstellt und schon einzellne Prozeduren, Funktionen und Variablen einträgt (nur die wichtigsten). Dann kann man anfangen sich von unten nach oben duch dem KlassenBaum zuarbeiten. Wenn man mit einer Klasse/Unit fertig ist hackt man sie ab. So hat man immer den überblick, was noch fehlt, bzw wo man gerade ist. Für die Mindmaps gibts auch haufen Freewares. Ich kann xMind empfehlen. Eine Mindmap könnte dann SO [http://img410.imageshack.us/img410/4751/mindmapx.jpg] aussehen.
Weiterhin hab ich festgestellt, das man neue Sachen, mit denen man sich noch nicht richtig auskennt erstmal in einem extra TestProjekt implementieren sollte (sofern das möglich ist). Wenn alles soweit funktioniert kann man die Unit/Klasse dann in das Hauptprojekt übernehmen.

MfG Bergmann.

catweasel - Di 15.12.09 00:11

Hi,

also das mit der MinMap ist eine ganz gute Idee, aber ich würde sie weniger für "Wieviel forms brauche ich" sondern mehr für "Welche algos brauche ich"
Ich kann jetzt nur von mir sprechen, aber gerade die GUI und das: was hat man auf einem Form, was auf einem anderen, ist meistens während der Entwicklung noch tsark im Fluss. (Oh, da reichen ja doch keine zwei drei Eingabefelder und ein Button mehr, da muss eine eigener Dialog her, etc).
<Anektote>
So hab ich das dann auch dmals in der Schule erlebt: Die Mitschüler hatten ein ausgeklügeltes Form zusammengeklickt. Sah super aus, aber beim Klick is nix passiert. Da blieb keine Zeit.
Bei mir kamen zwar die Zahlen nur in ein Memo gerotzt, aber bubble-gesorted wie es sein sollte.
</Anektote>

Das mit dem "Erst mal testen und dann ins Hauptprojekt übernehmen", das *kann* gutgehen, muss aber nicht. Gerade bei zu komplexen Projekten ist man dann in diesem Neben- oder Schmierzettelprojekten auf zuviele Sachen aus dem Hauptprojekt angewiesen (Typendeklarationen, andere Klassen, etc).

Ich habe schon alle Objekte von Anfang an im Haupt- und damit einzigen, Projekt. (Ausnahme natürlich Projekte die aus mehreren Anwendungen bestehen)
Zum Testen dient dann ein kleiner unscheinbarer Button irgendwo. Meistens ist das zu testende Objekt dann auch nur als lokale Variable dort deklariert.

Cheers,
Catweasel

catweasel - Di 15.12.09 07:51

Bergmann89 hat folgendes geschrieben :

Kommt drauf an was man fürn Projekt macht, wenn man einfach mal so nen Buton rein klicken kann geht das (mach ich auch öfter), aber manchma gehts eben auch in dem ExtraProjekt besser ^^

Und manchmal erstelle ich, bei total unabhängigen Klassen, auch ein Extraprojekt. (Aber mehr zum debuggen).
Womit bewiesen wäre: Es gibt keine allgemengültige Regel.

Aaaaber ih stelle mal ne andere Gretchenfrage: Wieviel Klassen sollte man pro Unit deklarieren?
Ich halte es normalerweise so: Eine Klasse, eine unit. Bei vielen Klassen wird das aber auch schnell unschön. Also packe ich beispielsweise zu einer TGraphicControl noch eine TWinControl als Containerklasse hinzu. Da diese recht simpel ist spar ich mir hierzu ne eigene unit.
Records, Konstanten sowie klassenlose Funktionen kommen auch in ine extra unit.

Wie haltet ihr das denn so?

und: Initiaisiert ihr variablen im OnCreate(), oder im initialization Abschnitt der unit? (Ich bevorzuge letzteres)

Catweasel

0xDEAD - Di 15.12.09 09:55

Viele eurer Tipps sind für mich nichts neues.
Aber danke für die Anregungen einige werden da bestimmt noch was hilfreiches finden.

Bei mir ist häufig das Problem, dass ich mir nicht sicher bin, welche Methode für welche Funktion die beste ist.

Beispiel:

Rufe ich einen Dialog über eine Message auf?
Oder mach ich es mir einfach und rufe den Dialog über eine globale Variable?
Oder geht das nicht auch über die Objektablage?

Oder:

Benutze ich das ErbauerMuster oder direkt ne Faktory oder code ich jedes "Produkt" über eine Prozedur.

... und irgendwann drehe ich mich im Kreis und weiß nicht mehr wo ich eigentlich hin will.

Wahrscheinlich kann man so was nur durch Programmieren kompensieren. Es fehlt mir vermutlich einfach an Erfahrung.

Und jetzt mal unter uns. *flüster*
Durch diese ewige Abschätzerei und Überlegung find ich mich auch extrem langsam.

catweasel - Di 15.12.09 16:50

alzaimar hat folgendes geschrieben :

Im OnCreate werden Felder initialisiert, im initialization-Abschnitt globale Variablen. Da globale Variablen in den seltensten Fällen sinnvoll sind, erübrigt sich i.a. Letzteres.

Ich kenne viele Leute die eine globale Variable, sagen wir mal:

Delphi-Quelltext

1:
2:

var
  path : string;

deklarieren, und dann im Form.OnCreate() ein

Delphi-Quelltext

1:	path := extractfilepath(paramstr(0));

dahintersetzen.

Jetzt kann man natuerlich streiten ob "path" als Klassenfeld besser aufgehoben ist oder als Variable.....

Hmmm fur mich sind die Faelle von globalen variablen gaaar nicht so selten sinnlos.
Oftmals braucht man genauso etwas wie eine path variablen, ohne das man das als Eigenschaft der Klasse haben moechte.

Aber man kann ja so vieles: Globale variable, public field, private field mit public get und set methoden (vielleicht noch als deklarierte property)....

... Gibt also viele Moelichkeitn.. Hab alle schonmal irgendwo gesehen. Deshalb meine Neugier....

Catweasel

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!