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