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');

[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 von a.def:

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 von a.def:

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 von Lemmy:

Zitat von a.def:

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 aber 1 ist mehr als 0

Zitat von Lemmy:

Zitat von a.def:

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.

[himitsu]

Statt Record eine Class Abstract oder 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 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.

[Uwe Raabe]

Zitat von freimatz:

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