Unit-Design - was bevorzugt ihr?

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1357927)

Da OOP ginge es ja eher in Richtung 1.

Aber es kommt immer darauf an, ob und wie man seine "Methoden" logisch und funktional zusammenfasst.

:thumb:

[a.def]

Zitat:

Zitat von himitsu (Beitrag 1357927)

Aber ich würde bei Records auf jeden Fall noch

Delphi-Quellcode:

static

mit angeben, um den "unsichtbaren" Self-Parameter loszuwerden, da Self ohne Vererbung keinen Sinn macht.

Wie genau meinst du das?

Zitat:

Zitat von himitsu (Beitrag 1357927)

Ich verwende auch gern Record statt Class, da dort der RTTI-Overhead einen Hauch geringer ist, aber im Prinzip kann es jeder machen wie er will.
Record verwende ich quasi so ähnlich wie den "Namespace" in anderen Sprachen.

Ich glaube genau das war sogar der Grund, weshalb ich #1 überall verwende. Vorher musste ich immer für jede Unit eine Instanzenvariable anlegen. Das ging mir irgendwann auf die Nerven.

[Zacherl]

Zitat:

Zitat von a.def (Beitrag 1357929)

Zitat:

Zitat von himitsu (Beitrag 1357927)

Aber ich würde bei Records auf jeden Fall noch

Delphi-Quellcode:

static

mit angeben, um den "unsichtbaren" Self-Parameter loszuwerden, da Self ohne Vererbung keinen Sinn macht.

Wie genau meinst du das?

Ohne

Delphi-Quellcode:

static

wird den Methoden ein versteckter

Delphi-Quellcode:

Self

Parameter übergeben, welcher die aktuelle Objektinszanz beinhaltet (bzw. einen Zeiger auf die TClass, sofern es sich um eine Class-Method handelt). Das ist natürlich relativ witzlos, wenn man den

Delphi-Quellcode:

record

eh nur als Namespace benutzt und nichtmal instanziiert.

[a.def]

Im Beispiel #1 haben die Methoden doch static :P

Delphi-Quellcode:

type
 TTestUnit = record
 private
 public
  class procedure TestProzedur(const AParam: string); static;
 end;

[p80286]

Ist Euch eigentlich aufgefallen, das Ihr nicht über "Unit-Design" sondern über die Anwendung von Records contra Classes diskutiert?
Beides hat seine Berechtigung und ich setze jeweils das ein was mir besser in den Kram passt. Und das schließt eine spätere Änderung nicht aus.

Da gibt es kein entweder oder.
(und ich habe noch jede Menge Units, die einfach nur Funktionssammlungen sind. Solange die vernünftig arbeiten, werde ich da nichts ändern.

Gruß
K-H

[jaenicke]

Ich lege alles in Klassen. Dort benutze ich dann aber auch noch Records zur weiteren Strukturierung. Zum Beispiel gibt es dann nicht (als fiktive Beispiele):

Delphi-Quellcode:

StrToPerson
TryStrToPerson
HashMD5Salted
usw.

sondern:

Delphi-Quellcode:

TStringTools.StrTo.Person
TStringTools.TryStrTo.Person
TStringTools.Hash.MD5Salted
usw.

Auf die Weise findet man finde ich sehr viel schneller was man sucht, weil man nicht eine hingeworfene Anzahl an Funktionen hat, sondern eine saubere Struktur, durch die man per Syntaxergänzung schnell durch ist.

Einen größeren Unterschied macht die Sache auch bei der Umbenennung einer Unit.
Schreibt man den Unitnamen immer vor eine lose Funktion, muss man diesen unterhalb von implementation an x Stellen anpassen. Schreibt man dort nur den Klassennamen hin, beschränkt sich die Änderung jeweils auf die uses Klausel.
Schreibt man den Unitnamen aber nicht hin bei losen Funktionen, weiß man nicht woher die Funktionen stammten...

Die beiden großen Vorteile sehe ich, wenn man nicht lose Funktionen nutzt.

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1357946)

Einen größeren Unterschied macht die Sache auch bei der Umbenennung einer Unit.
Schreibt man den Unitnamen immer vor eine lose Funktion, muss man diesen unterhalb von implementation an x Stellen anpassen. Schreibt man dort nur den Klassennamen hin, beschränkt sich die Änderung jeweils auf die uses Klausel.

Bei alten gereiften Funktionen wird sich da wenig ändern.

Zitat:

Zitat von jaenicke (Beitrag 1357946)

Schreibt man den Unitnamen aber nicht hin bei losen Funktionen, weiß man nicht woher die Funktionen stammten...

So'n Quark, natürlich weiß ich sofort aus welcher Unit was kommt...:stupid:

Aber ernsthaft gefragt, schleppe ich nicht irgendwelchen Overhead mit, wenn ich irgendwelche Allerweltsfunktionen in eine Klasse packe?

War da nicht mal was wie, nur was gebraucht wird, wird auch kompiliert?

Gruß
K-H

[a.def]

Zitat:

Zitat von p80286 (Beitrag 1357947)

So'n Quark, natürlich weiß ich sofort aus welcher Unit was kommt...:stupid:

Installier dir mal JCL. Dann kommt StrToInt oder IntToStr (welches genau weiß ich nicht mehr) aus der JCL statt von den Delphi-eigenen Sourcedateien :stupid:

[himitsu]

Kompiliert wird immer alles.
Was am Ende ins Programm gelinkt wird, ist eine andere Sache.
Editor -> PreCompiler (LLVM bei den neueren Compilern) -> Compiler -> Linker -> AfterBuildZeugs

Auch bei Klassen/Records können Felder/Methoden weggelassen werden, oder gar die ganze Klasse (außer man ist so intelligent und bindet z.B. in Initialization eine Initprozedur ein, anstatt den Class-Constructor zu nutzen)


Natürlich ist genau definiert wann welche Mehtode verwendet wird, wenn es mehrere gleichnahmige gibt,
aber das muß nicht immer mit dem übereinstimmen, was man grade glaubt zu wissen, falls man z.B. diese andere IntToStr/StrToInt nicht kennt oder grade im Kopf hat.

[jaenicke]

Zitat:

Zitat von p80286 (Beitrag 1357947)

Bei alten gereiften Funktionen wird sich da wenig ändern.

Bei uns lagen allgemeine Units bis vor ein paar Jahren relativ ungeordnet herum.
Das haben wir dann neu strukturiert, so dass aus string_tools.pas zuerst StringUtils.pas und nun Common.Utils.StringTools.pas wurde (natürlich auch im Verzeichnis common/utils).

Neue Unit landen gleich in dieser geordneten Struktur. Insofern wurden bei uns eher die alten Unit umbenannt.

Aber das ist natürlich bei jedem anders, das sollte kein Widerspruch sein. ;-)