Hallo zusammen,
es geht hier um eine grundsätzliche Vorgehensweise beim programmieren.

Jede Funktion/Prozedur erhält immer höchstens einen Parameter.
Egal ob von aussen in die Funktion ein oder mehrere Objekte/Werte zugewiesen werden müssen,
es wird immer ein Objekt einer Transporter Klasse erzeugt und dieses Objekt ist der Parameter.

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyTransporter = class
    ...
  public
    ...
    property Count: Integer read GetCount write SetCount;
    property Text: String read GerText write SetText;
end;


...
procedure TOtherClass.DoSomething(AValue: TMyTransporter);
begin
  ...
end;
...

Was haltet ihr von solch einer Vorgehensweise?

Nix?

Was meinst Du mit jeder Funktion? Alle zukünftigen Funktionen/Proceduren Deiner Klassen und Hilfsrotinen?

Also stelle mir das sehr übel vor (sofern ich das richtig verstanden habe)... Raterei, welche Werte die Funktion braucht, da keine sprechenden Parameter... haufenweise Prüfungen in den Funktionen (Reihenfolge der Parameter, Wertegültigkeit, Anzahl etc.)

Evtl. müsstest Du die Idee auch noch etwas genauer beschreiben. So wie es jetzt für mich klingt, klingt es nicht sehr sinnvoll.

Wenn eine Funktion mehr als 3 Parameter hat und häufiger aufgerufen werden soll, dann entwerfe ich einen ParameterRecord, der übergeben wird (vgl. WinApi)

Ich denke man sollte sich nicht konkret auf Anzahl der Parameter festlegen, jedoch finde ich eine Kapselung von Informationen in Klassen grundsätzlich erstmal gut. Außerdem sollte jede Klasse ihre eigene Aufgabe haben. Wenn die Klassen sozusagen "lose gekoppelt" sind ist es meiner Ansicht nach kein stilistisches Verbrechen auch mehrere Parameter pro Methode zuzulassen.

Viele Grüße

Zitat von Satty67:

Was meinst Du mit jeder Funktion? Alle zukünftigen Funktionen/Proceduren Deiner Klassen und Hilfsrotinen?

Ja ich rede von meinen eigenen Klassen.

Zitat von Satty67:

Also stelle mir das sehr übel vor (sofern ich das richtig verstanden habe)... Raterei, welche Werte die Funktion braucht, da keine sprechenden Parameter... haufenweise Prüfungen in den Funktionen (Reihenfolge der Parameter, Wertegültigkeit, Anzahl etc.)

Jede Transporterklasse wäre für die entsprechende Funktion zugeschnitten.
Prüfungen können direkt innerhalb der Set-Methode der Transporter-Klasse durchgeführt werden.
Der Zugriff innerhalb der Funktion läuft dann genauso, als würdest du die Werte als Parameter übergeben.

Zitat von Satty67:

Wenn eine Funktion mehr als 3 Parameter hat und häufiger aufgerufen werden soll, dann entwerfe ich einen ParameterRecord, der übergeben wird (vgl. WinApi)

In Prinzip ist es nichts anderes als was ich gerade beschreibe.


Edit:
Ein Beispiel, worum es mir eigentlich geht.
Stellt euch vor ihr habt eine Klasse in der es eine Funktion gibt um TCP Netzwerkverbindungen aufzubauen. Diese Funktion erhält einen Parameter von einer Klasse, die TCP Verbindungsinformationen als properties besitzt(IP bzw. Hostname, Port, usw.)

Ihr entwickelt irgendwann eine neue Klasse, diese Klasse braucht weswegen auch immer auch diese Informationen. Statt in beiden Funktionen eine Liste an Parametern einzubauen, wäre es nun möglich bei beiden Funtionen ein Objekt dieser Transportklasse zu übergeben.

Natürlich geht auch der Weg, daß man solch eine Funktion als eine neue Klasse konzipiert wird und diese Parameter als properties dieser Klasse zur Verfügung stellen könnte.
Auch ein schöner Weg wie ich finde.

Es gibt halt mehrere Wege. Ich sage nicht der Weg ist gut oder schlecht, sondern möchte gerne Meinungen hören.

Zitat von Tyrael Y.:

Zitat von Satty67:

Wenn eine Funktion mehr als 3 Parameter hat und häufiger aufgerufen werden soll, dann entwerfe ich einen ParameterRecord, der übergeben wird (vgl. WinApi)

In Prinzip ist es nichts anderes als was ich gerade beschreibe.

Das ist für eine Vielzahl von Fällen auch sinnvoll, aber man sollte nicht für jede Funktion, die mehrere Eingabe verarbeitet einen ParameterRecord oder eine ParameterKlasse entwerfen, finde ich. z.B. eine Funktion, die zwei TMyTransporter entgegennimmst wäre es nicht unbedingt sinnvoll diese beiden Klasse nochmal in eine Klasse zu kapseln...

Das größte Problem dürfte die Verwendung deiner Klassen sein. Du müsstest Dir für jeden Aufruf eine Transporter-Instanz erstellen, diese befüllen, deine Funktion aufrufen und dann den Transporter wieder freigeben. Was hat das für einen Sinn, außer den Code aufzublähen und deinen Anwendung fehleranfälliger und extrem unperformant zu machen?

Auch die Vorgehensweise von Satty67 halte ich für überflüssig (Bei mehr als drei Parametern einen Record definieren). Normalerweise ist es ein Designfehler, eine Funktion mit vielen Unabhängigen zu erstellen. Dann sollte man eine Klasse erstellen, die diese Funktion implementiert und die Parameter über die Properties befüllen. 'Normalerweise' bedeutet natürlich, das es auch Ausnahmen gibt.

Eine Funktion mit vielen Parametern ist i.A. so komplex, das es eben eine eigene Klasse gehört.

Ich finde eigentlich, dass es sehr viele Funktionen gibt, die mehr als ein Parameter brauchen. Man sieht die oft nur nicht, weil die bereits in einem Standard ParameterRecord versteckt sind (z.B. TRect).

Das Beispiel von Tyrael mit Connection-Daten ist ja auch typisch für viele Parameter, wo die Funktion u.U. nicht andres macht, als Connecten. Aber das zeigt auch, was wohl alzaimar gemeint hat. TConnection ist eine Klasse, die mit properties gefüllt wird und eine Methode connect besitzt.

Also ich finde soetwas lohnt sich nur, wenn die Funktion mehrmals/oft aufgerufen wird, sich nur wenige Parameter ändern und zwischendurch die Parameter nicht freigegeben werden.

Wem dabei das Speichermanagement von Objekten nicht gefällt, der kann ja auch einen Record verwenden, die Felder ins Private verschieben und den Zugriff via Properties ermöglichen.

Zitat von Tyrael Y.:

Natürlich geht auch der Weg, daß man solch eine Funktion als eine neue Klasse konzipiert wird und diese Parameter als properties dieser Klasse zur Verfügung stellen könnte.
Auch ein schöner Weg wie ich finde.

Sag ich ja auch.
Es macht ja auch Sinn in solchen Fällen statt einer "großen" Funktion eine "kleine" Klasse zu erstellen.

Ich gebe zu ich benutze oft beides.
Meist fange ich mit dem Weg der einzelen Funktion mit einem "Transporter" Objekt als Parameter an und bei weiteren Erweiterungen wird aus solch einer Funktion eine neue Klasse.