Unit-Design - was bevorzugt ihr?

[a.def]

Ich habe mal in einem Forum eine Art und Weis gesehen eine Unit anzulegen, die mir noch immer zu denken gibt. Ich bin mir nicht mehr sicher ob das in diesem Forum war oder woanders.
Die Suche hilft mir da nicht weiter. Im Grunde war es eine Unit wie die erste.
Welche bevorzugt ihr?

#1

Delphi-Quellcode:

unit uTest;

interface

// uses ;

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

implementation

// uses ;

class procedure TTestUnit.TestProzedur(const AParam: string);
begin
 // do some stuff
end;

end.

// Aufruf: TTestUnit.TestProzedur('123');

oder eher #2

Delphi-Quellcode:

unit uTest;

interface

// uses ;

procedure TestProzedur(const AParam: string);

implementation

// uses ;

procedure TestProzedur(const AParam: string);
begin
 // do some stuff
end;

end.

// Aufruf: uTest.TestProzedur('123');

:idea:

[TiGü]

Lieber Nr. 1.

[freimatz]

Weder noch.
Globale Methoden werden kaum besser wenn man sie in einen record packt.

[a.def]

Interessant. Ich hätte eigentlich gedacht, dass #1 total gehasst wird.
Ich persönlich mag vom Code her eher #1. Aber wenns um Änderungen geht ist #2 besser, da hier weniger zu ändern ist.

[Lemmy]

Zitat:

Zitat von a.def (Beitrag 1357919)

Interessant. Ich hätte eigentlich gedacht, dass #1 total gehasst wird.

ein klein wenig dünnes Eis? bei der geringen Datenmenge eine solche Schlussfolgerung?

Zitat:

Zitat von a.def (Beitrag 1357919)

Aber wenns um Änderungen geht ist #2 besser, da hier weniger zu ändern ist.

aha.. inwiefern ist da weniger zu ändern wenn Änderungen anstehen (z.B. ein weiterer Parameter kommt dazu)

[a.def]

Zitat:

Zitat von Lemmy (Beitrag 1357920)

Zitat:

Zitat von a.def (Beitrag 1357919)

Interessant. Ich hätte eigentlich gedacht, dass #1 total gehasst wird.

ein klein wenig dünnes Eis? bei der geringen Datenmenge eine solche Schlussfolgerung?

Hast ja recht :stupid: aber 1 ist mehr als 0 :cyclops:

Zitat:

Zitat von Lemmy (Beitrag 1357920)

Zitat:

Zitat von a.def (Beitrag 1357919)

Aber wenns um Änderungen geht ist #2 besser, da hier weniger zu ändern ist.

aha.. inwiefern ist da weniger zu ändern wenn Änderungen anstehen (z.B. ein weiterer Parameter kommt dazu)

Ich meinte (aber schrieb es nicht) eigentlich das Hinzufügen von Prozeduren.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1357918)

Weder noch.
Globale Methoden werden kaum besser wenn man sie in einen record packt.

Stellst du damit den Sinn globaler Methoden bzw. Klassenmethoden generell in Frage? Ich finde, die haben schon ihren Einsatzbereich immer da, wo keine Instanz für die Funktion notwendig ist. Im Gegenteil würde ich es als äußerst störend und überflüssig finden, wenn jedesmal für den Aufruf eine Instanz erstellt und wieder freigegeben werden müsste.

[Klaus01]

.. wenn Du #1 verwendest kannst Du im Source(in dem die Unit verwendet wird) codecompletion verwenden.
Bei #2 nicht.

Grüße
Klaus

[bra]

Ich glaube freimatz meinte, dass TTestUnit ein record und keine class ist. Wobei das in diesem speziellen Fall keinen Unterschied machen dürfte.
Ich persönlich bevorzuge auch die Variante #1 (aber eher als class).

[himitsu]

Statt

Delphi-Quellcode:

Record

eine

Delphi-Quellcode:

Class Abstract

oder

Delphi-Quellcode:

Class Sealed

macht von der "Verwendung" her keinen großen Unterschied.

Der "Unterschied" ist nur in Bezug auf Vererbung und die RTTI bezogen.
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.

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.

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

[Rollo62]

Wo wir schon bei Units sind ...

Ich benutze auch gerne weitere Verschachtelungen durch .
in der Art

String.Utils.Converter.pas

Das mache ich mittlerweile in vorrauseilendem Gehorsam, also auch
wenn es String.pas und String.Utils.pas noch gar nicht gibt :stupid:


Rollo

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1357953)

Bei uns lagen allgemeine Units bis vor ein paar Jahren relativ ungeordnet herum.

Der wesentliche Unterschied hier ist wohl wir und ich. Solange ich mich in meinem Chaos zurecht finde geht's, sobald ein zweiter hinzu kommt, ist das wohl eher kontraproduktiv. Aber wie immer kommt's es auf den Einzelfall an.

Gruß
K-H

[a.def]

Ich ändere gerade auch alles um, damit mein Chaos etwas geordneter wird.
In eine eben angelegte Datei habe ich bereits 22 Methoden gesteckt. Die Datei hat mittlerweile komplett 745 Zeilen.
Bis wie viel Zeilen ist eine Datei denn noch OK, wenn thematisch alle Methoden die da drin sind zusammenpassen?

[Mavarik]

Zitat:

Zitat von a.def (Beitrag 1357968)

Ich ändere gerade auch alles um, damit mein Chaos etwas geordneter wird.
In eine eben angelegte Datei habe ich bereits 22 Methoden gesteckt. Die Datei hat mittlerweile komplett 745 Zeilen.
Bis wie viel Zeilen ist eine Datei denn noch OK, wenn thematisch alle Methoden die da drin sind zusammenpassen?

Ich denke das ist gar nicht die Frage...

Ich habe auch noch Projekte wo es Units gibt, die gesammelte Proceduren und Funktionen habe... (> 7000 LOC)

Da hat aber auch so gut wie keine Procedure etwas mit der anderen zu tun... Und i.d.R haben die alle 2 Versionen

Delphi-Quellcode:

Procedure Foo(Const AValue : AnsiString);overload;
Procedure Foo(Const AValue : WideString);overload;

Ich rede mich raus mit : Gewachsener Code seit 1984. :stupid:

Wenn ich Proceduren für Typen baue, dann immer in einer Class Abstract oder z.B. für TArray<T> hier ist alleine die Klassendefinition fast 200 LOC.

Mavarik

[mm1256]

Zitat:

Zitat von a.def (Beitrag 1357968)

Ich ändere gerade auch alles um, damit mein Chaos etwas geordneter wird.

Das glaube ich ist der Punkt: Irgendwann wird ein ungeordnetes System chaotisch. Wichtiger ist also meiner Meinung nach mehr, dass man überhaupt ein System verwendet. Welches ist dann wiederum davon abhängig, ob man das System nur für sich selber verwendet, oder in der Gruppe.

Zitat:

Zitat von a.def (Beitrag 1357968)

Bis wie viel Zeilen ist eine Datei denn noch OK, wenn thematisch alle Methoden die da drin sind zusammenpassen?

Wenn alles was drin steckt thematisch zusammen passt, und entsprechend geordnet ist, gibt es wahrscheinlich keine Größenvorgabe. Jedenfalls mache ich mir keine. 8-)

Zitat:

Zitat von Mavarik

Procedure Foo(Const AValue : AnsiString);overload;
Procedure Foo(Const AValue : WideString);overload;

Darüber muss man sich nicht raus reden. Solche Leichen hat wohl fast jeder im Keller, der die Ansistring-Umstellung hinter sich hat :thumb:

[Rollo62]

Gewachsene Libraries sind/werden wohl immer chaotisch, ich sehe das ganz locker.

Man sollte nur permanent an Verbesserungen und Reduzierungen von Redundanz und Kopplung arbeiten.
Dann wir schon alles gut :stupid:

Hauptsache der Codeowner kennt sich im Dschungel noch aus.

Rollo

[a.def]

Zitat:

Zitat von mm1256 (Beitrag 1358086)

Darüber muss man sich nicht raus reden. Solche Leichen hat wohl fast jeder im Keller, der die Ansistring-Umstellung hinter sich hat :thumb:

Meine ist aktuell....

Delphi-Quellcode:

function IfThen(aValue: Boolean; const ATrue, AFalse: Integer): Integer; overload;
begin
 if aValue then
  Result := ATrue
 else
  Result := AFalse;
end;

function IfThen(aValue: Boolean; const ATrue, AFalse: string): string; overload;
begin
 if aValue then
  Result := ATrue
 else
  Result := AFalse;
end;

function IfThen(aValue: Boolean; const ATrue, AFalse: Boolean): Boolean; overload;
begin
 if aValue then
  Result := ATrue
 else
  Result := AFalse;
end;

Mir ging es auf die Nerven, dass es von offizieller Seit nur eine davon gab. Also habe ich mir die genommen, in meine Sammlung gepackt und zwei hinzugefügt.
Auf diese Art und Weise konnte ich viel Code sparen alà

Delphi-Quellcode:

// Vorher
if A = B then
 s := 'C'
else
 s := 'D';

// Nachher
s := IfThen(A = B, 'C', 'D');

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1358119)

Mir ging es auf die Nerven, dass es von offizieller Seit nur eine davon gab.

In System.Math sind noch sechs andere. Fehlt nur die für Boolean.

[a.def]

Zitat:

Zitat von Uwe Raabe (Beitrag 1358122)

In System.Math sind noch sechs andere.

Kommt mir ein bisschen vor wie die Suche nach den Eiern an Ostern :stupid:

[DeddyH]

Könnte man das nicht auch so lösen (ungetestet)?

Delphi-Quellcode:

type
  TGenericCompare<T> = record
  public
    class function IfThen(Expression: Boolean; const AThen, AElse: T): T; static;
  end;

class function TGenericCompare<T>.IfThen(Expression: Boolean; const AThen,
  AElse: T): T;
begin
  if Expression then
    Result := AThen
  else
    Result := AElse;
end;

Aufruf dann z.B.

Delphi-Quellcode:

procedure TfrmTest.ButtonTestClick(Sender: TObject);
var
  s: string;
begin
  s := TGenericCompare<string>.IfThen(1 = 1, 'Ja', 'Nein');
  ShowMessage(s);
end;

[jaenicke]

Kann man, so etwas ähnliches benutze ich selbst auch, nur dass ich den generischen Parameter der Methode statt der Klasse bzw. dem Record gegeben habe.

[Uwe Raabe]

Der Nachteil dieser Funktion im Gegensatz zum direkten Ausschreiben ist halt, daß beide Ergebnisse als Funktionsparameter ausgewertet werden. Das mag nicht immer wünschenswert sein:

Delphi-Quellcode:

IfThen(Sender <> nil, Sender.Classname, '');

[DeddyH]

War ja nur 'ne Idee, zig Überladungen für alle möglichen Datentypen machen den Code halt unübersichtlich IMO.

[jaenicke]

Ihr sprecht ja von zwei verschiedenen Sachen. Uwes Hinweis gilt ja für beide Lösungen mit IfThen. Deshalb ist IfThen ja auch nicht sinnvoll für zeitkritische Codestellen.

[Namenloser]

Zum Ursprungsthema: Ohne weitere Information würde ich mal sagen #2. Man muss ja nicht alles machen wie Java.

Wenn es eine globale Funktion ist, dann ist es halt eine globale Funktion. Wird auch nicht besser, wenn man noch eine Klasse drumherum packt. Das ist eigentlich nur Boilerplate-Code, der keinen zusätzlichen Nutzen bringt.

Das "Namespace" oder Code-Completion-Argument lasse ich auch nicht gelten, denn dazu kann man auch genau so gut den Unit-Namen verwenden (Weiß vielleicht nicht jeder, vor allem wenn er von einer anderen Sprache wie C++ kommt, die kein richtiges Modul-System haben).

In Pascal-Sprachen stellt die Unit an sich schon eine Kapselung dar, da braucht man nicht noch eine Kapselung in der Kapselung.

Das ist wohl diese Java-Denke. "Alles muss ein Objekt sein". OOP ist schön und gut, da wo es Sinn macht, aber es ist auch nicht das einzige, was es gibt.

[a.def]

Zitat:

Das "Namespace" oder Code-Completion-Argument lasse ich auch nicht gelten, denn dazu kann man auch genau so gut den Unit-Namen verwenden (Weiß vielleicht nicht jeder, vor allem wenn er von einer anderen Sprache wie C++ kommt, die kein richtiges Modul-System haben).

Und wenn der Namespace TStringUtils ist und der Unit-Name _string_utils.pas?

Da bevorzuge ich lieber die Eingabe von TStringUtils im Code :P

[Namenloser]

Warum nicht einfach der Unit einen schöneren Namen geben?

[p80286]

Zitat:

Zitat von Namenloser (Beitrag 1358193)

Wenn es eine globale Funktion ist, dann ist es halt eine globale Funktion. Wird auch nicht besser, wenn man noch eine Klasse drumherum packt. Das ist eigentlich nur Boilerplate-Code, der keinen zusätzlichen Nutzen bringt.

Was das angeht, hat mich Sebastian überzeugt #16, wenn Du in den Dateien aufräumst, hast Du mit Klassen weniger Arbeit.

Gruß
K-H

[a.def]

Zitat:

Zitat von Namenloser (Beitrag 1358196)

Warum nicht einfach der Unit einen schöneren Namen geben?

Wäre alles überhaupt kein Problem. Aber leider kann man die Dateien nicht so sortieren wie man es gerne hätte :(

[hoika]

Hallo,
da war doch diese Unit mit 32.000 Zeilen Quellcode unter Delphi 1,
zum Glück kam D2 und ich konnte endlich > 32.767 ;)