Organisieren von großen Programmen

[himitsu]

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).

[s.h.a.r.k]

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.

[Assarbad]

Zitat von himitsu:

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?

[nachti1505]

Zitat von sx2008:

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?

[Assarbad]

Zitat von nachti1505:

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?

Ich sehe da keinen Unterschied. Dem Linker mußt du doch trotzdem noch sagen was er zusammenlinken soll. Also irgendein Teil deines Codes wird wohl zwangsläufig die Unit per uses einbinden (bspw. von der .dpr aus).