Programm aufsplitten in Einzelaufgaben?

[moelski]

Moin !

Ich hätte da mal ne generelle Frage mit der Bitte um Tips und Meinungen. Und zwar proggen wir seit längerem an dieser Anwendung hier: LogView. Von Version zu Version wird nun der Quelltext immer umfangreicher ... Deshalb hatte ich heute Morgen die Idee, ob es nicht sinnvoller wäre, die eine große Anwendung in kleine Einzelanwendungen aufzusplitten.

Vielleicht sollte ich mal kurz die Funktion unserer Soft beschreiben. Also, es gibt einen Part, der serielle Daten von einem Ladegerät entgegen nimmt. Dann gibt es einen Part der die ganze Umrechnung dieser Daten übernimmt. Und dann gibt es einen Part, der die Anzeige macht. Wenn man das nun alles in einzelne Anwendung auslagern würde, dann hätte man den Vorteil, dass man alles einzeln weiterentwickeln könnte.

Was ich mich nun Frage wäre folgendes:
- Macht sowas generell Sinn, oder sollte man es eher lassen?
- Was gäbe es für Alternativen? (im Bezug auf kleinere Einzelaufgaben)
- Wenn man das so macht wie beschrieben, wie könnte man Daten zwischen den einzelnen Modulen übergeben?

[Bernhard Geyer]

Ich würde das nicht unbedingt anstreben, außer du willst die Softwarebestandteile einzeln verkaufen.
Viel wichtiger ist das du deine Objekt/Klassen-Struktur gut getrennt/gekapselt hast. Evtl. für einzelne Komponenten Unittests/Simulationsgegenstücke geschrieben hast. Damit lassen sich auch große Projekte (selbst haben wir 1 Mio. Quellcodezeilen) in einem Projekt/Programm handeln.

[mschaefer]

Moin, moin,

ja wie Bernhard das schon schreibt ist es nicht unbedingt das Ziel. Würde es davon abhängig machen ob der Anwender einzelne Aufgaben seperat ausführen kann. Das heisst, die Aufteilung des Programmes in einzelne Executes würde ich aus Anwendersicht, nicht aber aus entwicklungstechnischer Sicht vorhnehmen.

Kann mir das zum Beispiel gut bei einer Auftragsbearbeitung vorstellen, wo Artikel- und Adressverwaltung in getrennte Programme aufgeteilt sind. Bei Eurer Anwendung verwirrt das eher und noch schlimmer, es wirkt für den Anwender kompliziert.

Was Ihr aber machen könnt, wäre die Aufteilung in Hauptanwendung und dll´s. Die Größe der Anwendung in der IDE ist da nicht das Hauptargument, aber man kann an so aufgeteilten Systemen gut mit mehreren Entwicklern parallel arbeiten und fördert quasi nebenbei die Übersichtlichkeit in der IDE.

Grüße // Martin

[moelski]

Moin !

Ok, also schonmal keine Aufsplittung.

Zitat:

wäre die Aufteilung in Hauptanwendung und dll´s

Das sowas geht habe ich schon mehrfach gelesen, aber noch nie gemacht. Kannst du mir kurz beschreiben wie man sowas angehen könnte?
Gibt es zu diesem Thema irgendwo ein gutes Tutorial?

[Jelly]

Zitat von mschaefer:

Was Ihr aber machen könnt, wäre die Aufteilung in Hauptanwendung und dll´s.

Oder in Packages (bpl) aufteilen, und die Anwendung dann "Mit Laufzeitpackages kompilieren". Das hat den Vorteil, wenn ein Programmieren an einem Tool was ändert, so muss er den anderen aus dem Team lediglich die bpl Datei zukommen lassen. Die müssen nicht mal ihre Anwendung neu kompilieren. So lassen sich Programmieraufgaben gut teilen...

Ist bei DLL genauso, nur bin ich der Meinung ist das Handling von Packages leichter wie das von DLLs.

Ein sehr anschauliches Beispiel von Packages gibst von unserem Mod alcaeus unter seiner Homepage -> Direktlink

[moritz]

Aufsplittung in DLL's würde ich dir nicht empfehlen, da es das ganze unnötig komplizierter macht - Du musst einfach drauf achten, wie die anderen schon sagen, dass du dein Programm schön objektorientiert aufbaust, gut kommentiert und evtl. sogar dokumentiert. Dann solltest du keine Probleme haben.
Ich habe in meinen Programmen immer eine TCore, die die Hauptklasse des Programms ist und alle Unterfunktionen bereitstellt. Wenn ich z.B. einen horizontalen Farbverlauf machen will, erledigt mir das Core.Graphics.GradientH, etc.

Gruß

[schöni]

Hallo!

Und trotzdem macht eine Aufteilung in Teilaufgaben letztlich Sinn. Egal, wie diese Teile dann implementiert werden. Wichtig isst, das die einzelnen Bausteine am Ende wieder zusammenpassen. Dazu gibt es mehrere Techniken:

Objektorientierung
Interfaces
Units
Dll-s

Wenn im Team gearbeitet wird, einigt man sich auf die Schnittstelle. Die Implementation realisiert dann jeder einzelne für seine Teilaufgabe. Und weil die Schnittstelle im ganzen Team bekannt ist, passt am Ende auch alles.

Welche Implementierungsvarianten hier in diesem Projekt, das Gegenstand dieses Threads ist, am sinnvollsten sind, kann ich aus der Ferne schlecht sagen, da ich den bisherigen Aufbau des Projektes nicht kenne. Vielleicht sind Interfaces ein möglicher Weg. Damit ergäbe sich eine Erweiterbarkeit der Anwendung mittels Plugins.

es grüßt

schöni

[mschaefer]

Moin zusammen,

ja beim Lesen des Threads in der Mittagspause scheint sich noch einiges zu Klären:
Die Objektorientierung sollte eigentlich klar sein, sonst kann man gleich VB mit OCX nehmen ...

Jelly´s Überlegung mit den Packages zu arbeiten ist bei reinen Delphianwendungen dem dll-Ansatz vorzuziehen. Man spart sich so etliches Tippen von Interfaces und Exportsectionen, es sei den, es sind nur wenige Übergabeparameter mitzugeben. In diesem Fall sind dll´s kein wirkliches Problem.

Ein Ansatz ist auch viel Funktionalität in die Komponenten zu verlagern. Die Variante hat sich bei mir durchgesetzt, bedingt aber regelmäßiges neukompilieren der eigenen Packages. Da hilft dann aber der dcc und eine Batchdatei. Das kann man dann gut mit dem Laufzeitpackageansatz verbinden. Wobei ich aber eher dazu neige, alles in die Exe zu kompilieren, damit der Anwender möglichst wenige Dateien hat, aber das ist auch etwas Philosophie.

Im Übrigen denke ich nicht, dass die Vorgehensweise wirklich Projektabhängig ist. Letzlich hängt es davon ab, ob ein Team aus reinen Delphi-Kandidaten besteht, oder verschiedene Sprachen bedient werden.

Fazit: Team- und Werkzeugabhängig.


Grüße // Martin

[Jelly]

Was noch nicht erwähnt wurde, ist die unbedingte, strikte Einhaltung der Trennung von Programmfuntionalität und der GUI. Das ist nicht immer evident, und ich machs leider auch nicht konsequent genug in meinen Projekten. Aber das spart einiges an Kopfzerbrechen, wenn mal einige Programmodule ausgelagert werden müssen in eine andere Applikation.

[GuenterS]

Zitat von schöni:

Hallo!

Und trotzdem macht eine Aufteilung in Teilaufgaben letztlich Sinn. Egal, wie diese Teile dann implementiert werden. Wichtig isst, das die einzelnen Bausteine am Ende wieder zusammenpassen. Dazu gibt es mehrere Techniken:

Objektorientierung
Interfaces
Units
Dll-s

Wenn im Team gearbeitet wird, einigt man sich auf die Schnittstelle. Die Implementation realisiert dann jeder einzelne für seine Teilaufgabe. Und weil die Schnittstelle im ganzen Team bekannt ist, passt am Ende auch alles.

Welche Implementierungsvarianten hier in diesem Projekt, das Gegenstand dieses Threads ist, am sinnvollsten sind, kann ich aus der Ferne schlecht sagen, da ich den bisherigen Aufbau des Projektes nicht kenne. Vielleicht sind Interfaces ein möglicher Weg. Damit ergäbe sich eine Erweiterbarkeit der Anwendung mittels Plugins.

es grüßt

schöni

Und ergänzend gibt es auch, wie eh auch schon angesprochen die Packages.

Ich persönlich würde Packages, den DLLs vorziehen ... versuch mal ein object aus ner DLL zu exportieren...