AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Organisieren von großen Programmen

Ein Thema von BlueLiquidCell · begonnen am 23. Nov 2010 · letzter Beitrag vom 25. Nov 2010
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von sx2008
sx2008

Registriert seit: 15. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#1

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 07:22
Es ist sinnvoll, den Sourcecode in zwei Teile zu zerlegen.
* Code, der nur für diese Anwendung benötigt wird
* Code, der so allgemein ist, dass er ohne weiteres auch in einer anderen Anwendung benützt werden kann
Letzteres ist besonders wertvoll, denn einmal programmiert aber mehrfach verwendet spart Zeit.

Ein Beispiel: in einer Anwendung musst du einen String zeichenweise umdrehen.
Der erste Ansatz wäre eine Schleife an Ort und Stelle zu verwenden und die Zeichen im String umzudrehen.
Schrittweise soll das jetzt verbessert werden.
Dir wird klar, dass man den Code nicht einfach so hinklatschen darf, sondern dass man daraus eine Funktion machen muss:
Delphi-Quellcode:
// String zeichenweise umdrehen
function ReverseString(const s:string):string;
...
Bislang hast du die Funktion nur ein einziges Mal gebraucht.
Aber jetzt brauchst du sie ein zweites Mal in einer anderen Unit.
Kein Problem, einfach kopieren.
Dann kommst du drauf, das Copy & Paste Programmierung doch nicht so toll ist(genauer gesagt ist es das Dümmste was man tun kann).
Also nicht kopieren, sondern die Deklaration der Funktion in der Interface-Abschnitt der Unit A schreiben
und dann in Unit B mit Uses einbinden.
Nun brauchst du die Funktion noch ein drittes Mal in Unit C.
Aber wenn du Unit A einbindest bekommst du nicht nur die Funktion ReverseString sondern auch anderes Zeug.
Du entscheidest dich die Funktion in eine eigene Unit namens "Utilities" zu verschieben.
In dieser Unit sammeln sich im Laufe der Zeit nützliche Funktion, Proceduren und Klassen an.
Du teilst die Unit "Utilities" in mehrere Units mit unterschiedlichen Themengebieten (Stringverarbeitung, Datenbankzugriff, Verschlüsselung, ...) auf.

Zum Schluss hast du eine Bibliothek bestehend aus versch. Units, die du auch in anderen Anwendungen einbinden kannst.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.584 Beiträge
 
Delphi 12 Athens
 
#2

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 07:54
Auslagern in eine DLL soll also besser sein, als ein einfaches Auslagern in verschiedene PAS?
Erhrlich gesagt, ist das sogar umständlicher, da man hier
a) schlechter Debuggen kann (da man im Allgemeinem eintweder die DLL oder die EXE debuggt)
und b) auch noch so Einiges aufpassen muß, wie Shared Memory und die getrennte RTTI, bei Verwendung von Objekten (also 'ne TStringList läßt sich nicht einfach so in beiden Teilen verwenden)

PS: Auch die kompilierten Daten werden nicht kleiner, nur weil man was in eine DLL auslagert.
Im Gegenteil, wenn man dieses nur bei einem Programm macht (also die DLLs nicht mit verschiedenen Programmen nutzt), dann werden es sogar mehr Daten.
Denn die DLL hat ja auch wieder Zusatzinfos und dann sind auch noch viele Daten doppelt (so z.B. die überall genutzten Delphi-Units, einige Resourcen usw.)
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
pixfreak

Registriert seit: 6. Jul 2007
112 Beiträge
 
Delphi XE3 Professional
 
#3

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 08:19
Moin zusammen,

in meinen C Projekten habe ich genau aus Grund der Vermeidung von DLLs zwecks Auslagerung Gebrauch von statischen Libs gemacht um wiederverwendbaren Code schnell einbinden zu können.

In Delphi schiebe ich wieder zu verwendenen Quelltext, der getestet und für gut befunden wurde, in ein extra "Erweiterungsverzeichnis", welches ich im Suchpfad habe. Dann brauche ich die Unit nur einbinden und alles ist gut. DLLs etc. würde ich nur nutzen, wenn die Funktionen von mehreren Programmen gebraucht werden, oder das Programm in mehreren Instanzen ausgeführt wird. Ansonsten hat man nur Ärger. Und bei der heutigen Hauptspeichergröße ist halt sowieso die Frage was ich will: eine etwas größere exe-Datei oder den Ärger mit DLLs (am besten noch mit inkomplatiblen Schnittstellen...)

Also mein Tip: Alles was funktioniert und nicht mehr angefasst werden soll, ab in eine eigene Unit etc. Ob jetzt als Klassen (vorzuziehen, Stcihwort Vererbung und Ableitung) oder prozedural, aber dann wird das eigentliche Progamm doch wieder übersichtlicher...


Viele Grüße

Pixfreak
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.584 Beiträge
 
Delphi 12 Athens
 
#4

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 08:31
PS: Alles was man als mehrere Prozeduren in einer Unit hat und welches logisch zusammen gehört, das kann man auch Problemlos in eine Klasse auslagern.

Und es wirklich nur Proceduren/Funktionen sind, dann als Klassenmethoden, also mit "class function DerName" deklariert.
So muß man keine Instanz der Klasse erstellen.

Delphi-Quellcode:
Procedure MacheIrgendwasFunktionA(die Parameter);
Procedure MacheIrgendwasFunktionB(die Parameter);
Procedure MacheIrgendwasFunktionC(die Parameter);

Aufruf: MacheIrgendwasFunktionC(übergebene Parameter);

Type TMacheIrgendwas = Class
  Class Procedure FunktionA(die Parameter);
  Class Procedure FunktionB(die Parameter);
  Class Procedure FunktionC(die Parameter);
End;

Aufruf: TMacheIrgendwas.FunktionC(übergebene Parameter);
Über TMacheIrgendwas. hat man dann in der Autovervollständigung dann auch noch eine nette Übersicht der Funktionen.

Und sobald in der Unit auch noch globale Variablen auftauchen, dann gehört sowas sowieso in eine Klasse.
Entweder ebenfalls als Klassenmethoden und mit Klassenvariablen. (als "Class Var" in der Klasse deklariert),
oder eben über ein instanziertes Objekt.
Wobei Letzeres einem erlaubt, die Klasse auch mehrmals im selben Projekt zu verwenden ... Über dar Klassenmethoden/-Variablen wäre nur ein einziges "Objekt" möglich.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.584 Beiträge
 
Delphi 12 Athens
 
#5

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 08:52
Na gut, wenn man es gleich von Anfang an als Klassen auslegt, dann ist der Mehraufwand nicht unbedingt sooooo groß.

Und wenn man diese Klassenmethoden nicht grade statisch deklariert (mit der Aufrufkonvention "static"), dann gibt es sogar noch einen unsichtbaren internen Parameter (das liebe SELF), welcher bei jedem aufruf soeiner Methode mit übergeben wird.

Ansonsten bringt es im Quellcode auch vorwiegend nur dann mehr Übersicht, wenn man z.B. mehrere ähnliche Funktionsgruppen in einier Unit auf mehrere solcher Klassen verteilt hat.
(Bei einer einzigen Klasse, in der Unit, mag es bestimmt ein winziges Bissl mehr Aufwand sein)

PS: Seit Delphi2006/TDE nutzte ich, bei Sowas, auch gern mal Recordmethoden.
Quasi fast das Selbe wie eine statische Klasse, welche man aber definitiv nicht instanzieren kann. (da das mit den abstracten Klassen ja nicht unbedingt gut funktionierte)

Und wenn es eine Funktion war, welche man zum Manipulieren eines Records nahm, dann ist das auch eine witzige Idee.
Denn früher mußte man den Record an die Funktion übergeben und nun ruft man die Funktion direkt über den Record auf.
(auch hier ist die Autovervollständigung wieder sehr nett, da man sich so die möglichen Funktionen zu diesem Record anzeigen lassen kann.

Ach ja, wer nun mein, daß es jetzt schwerer ist, Aufgrund der fehlenden Vererbung, dieses um Funktionen zu erweitern, der kennt die "Record Helper" noch nicht. ... Ja, das was es für Klassen (Class Helper) gibt, gibt es auch für Records.
(leider nicht für normale Typen ... TGUID hätte ich gern mal nachträglich um die zugehörigen Umwandlungsfunktionen erweitert, wie z.B. GuidToString)


PS: Diese PAS-Dateien von Delphi sind ja grade dazu da, daß man damit Alles schön aufteilen kann.
Nicht so wie in C, wo die ganze Includetechnik eigentlich das gesamte Programm nur in einer rießigen Quelltextdatei virtuellen verwaltet, wo eigentlich nichts wirklich voneinander getrennt ist (selbst wenn es in verschiedenen C- und H-Dateien drinsteht).
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu (24. Nov 2010 um 09:11 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von divBy0
divBy0

Registriert seit: 4. Mär 2007
Ort: Sponheim
1.021 Beiträge
 
Delphi XE2 Professional
 
#6

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 09:36
Was ist denn mit Packages und BPL?
Marc
9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die 10. summt die Melodie von Tetris... | Wenn das die Lösung ist, dann hätte ich gerne mein Problem zurück! | engbarth.es
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.584 Beiträge
 
Delphi 12 Athens
 
#7

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 09:44
Was ist denn mit Packages und BPL?
BPL ist auch "nur" eine DLL (mit speziellen Delphizusatzfeatures).
Also hier gilt das Selbe, wie bei den DLLs.
Wenn man das für nur ein Projekt macht, bringt es wohl nicht wirklich Vorteile.
Und bei Verwendung in mehreren Projekten muß man hier zusätzlich aufpassen.

PS: Die BPL muß mit dem selben Delphi-Compiler und der selben RTL/VCL-Version kompiliert sein, wie die EXE, welche sie verwenden will,
da ja die selben RTTI-Informationen verwendet werden müssen.
Dagegen ist eine "normale" DLL natürlich unabhängiger.

Wenn du also 2 Programme hast, welche die "gleiche" BPL nutzen will, aber das eine Programm noch in D2006 geschrieben ist, aber das andere Programm schon mit D2007, dann müssen auf dem Zielsystem irgendwie die BPLs für beide Delphiversionen installiert/vorhanden sein.
Und wenn das nun die einzigen Programme sind, welche diese BPLs nutzen, dann ist doch der Aufwand damit größer?
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#8

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 08:34
Bzgl. den DLLs kann man eben argumentieren, dass man bestimmte Funktionen eben in mehreren Programmen verwenden will, somit kann man das ja in eine DLL packen -- holt sich dabei aber auch einige Probleme mit ins Boot. Ich persönlich verzichte all zu gerne drauf.

@himitsu: Ich habe das auch mit diesen tollen statischen Klassenmethoden, bin aber aufgrund des Mehraufwandes nicht wirklich begeister von dieser Lösung. 100% OOP gibts eh nicht imho.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#9

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 13:44
Erhrlich gesagt, ist das sogar umständlicher, da man hier
a) schlechter Debuggen kann (da man im Allgemeinem eintweder die DLL oder die EXE debuggt)
Bedingtes Kompilieren? Anyone?
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von nachti1505
nachti1505

Registriert seit: 7. Apr 2007
188 Beiträge
 
Delphi 7 Enterprise
 
#10

AW: Organisieren von großen Programmen

  Alt 24. Nov 2010, 20:27
Du teilst die Unit "Utilities" in mehrere Units mit unterschiedlichen Themengebieten (Stringverarbeitung, Datenbankzugriff, Verschlüsselung, ...) auf.
Zum Schluss hast du eine Bibliothek bestehend aus versch. Units, die du auch in anderen Anwendungen einbinden kannst.
Ich nehme an, diese Unit binde ich dann nur per uses ein, oder? Was wäre denn der Unterschied zum Hinzufügen zum Projekt? Bzw. was ist generell der Unterschied zwischen uses und einbinden?
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:37 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz