Einfache proceduren/function sinnvoll?

[Chris30]

Hallo liebes Delphi-Praixs-Forum,
ich habe eine Frage zum Thema kurze proceduren/functions und wie sinnvoll sie sind.

Angenommen ich habe folgendes Beispiel:

Delphi-Quellcode:

TTest = class
wert1: String;
wert2: String;

function getWert1AsReal: real;
function getWert2AsReal: real;
end;


function TTest.getWert1AsReal: real;
begin
result := wandleStringZuReal(wert1);
end;

function TTest.getWert2AsReal: real;
begin
result := wandleStringZuReal(wert2);
end;

procedure main;
var 
test: TTest;
erg: real;
begin

test := TTest.Create;
test.wert1 := '2.3';
test.wert2 := '3.3';

//Variante 1
erg := wandleStringZuReal(test.wert1) + wandleStringZuReal(test.wert2); 
//Variante 2
erg := test.getWert1AsReal+ test.getWert2AsReal; 

end;

Ist die Funktion getWertXAsReal überflüssig?
Welche Vorteile und Nachteile bieten die beiden Varianten in Hinsicht auf Lesbarkeit, Wartbarkeit, Debugging und eventuell weitere sinnvolle Aspekte die Euch einfallen.
Sollte man grundsätzlich proceduren/function vermeiden die kürzer als ~5 Zeilen sind?
Wenn ja, wieso?

Ich würde mich über Antworten mit Argumenten sehr freuen.
Dankeschön

[runningsoft]

Die Frage ist sicherlich, wie häufig du deine Funktion/Prozedur voraussichtlich benötigst.

Angenommen, du musst deinen Einzeiler in getWertXasReal später ergänzen oder ändern, und hast die Funktion schon 10 mal verwendet, ist der Wartungsaufwand halt um einiges geringer, wenn du die Änderung nur innerhalb deiner Funktion vornehmen musst und nicht an jeder einzelnen Stelle im Quelltext, an der du die Berechnung ausführst.

Eine generelle Empfehlung, ab wann sich Mini-Funktionen/Prozeduren lohnen, kann man sicherlich nicht geben.

[himitsu]

Wenn es nur um den "minimalen" Overhead des Funktionsaufrufs (CALL) geht, dann die Methode/Funktion eben als inline deklarieren.



Und es gibt noch viele andere Lösungen: SubClass, RecordHelper, ...

Delphi-Quellcode:

erg := StrToFloat(Test.Wert1) + StrToFloat(Test.Wert2); 

erg := Test.Wert1.ToSingle + Test.Wert2.ToSingle;  // statt "String" mit einer Klasse, Record oder über Record-Helper

TStringHelper.ToSingle

[Redeemer]

Unabhängig von der Fragestellung: Das Beispiel würde man so nicht machen. Was dir allgemein fehlt, sind Eigenschaften. Spätestens wenn man öfter lesend als schreibend drauf zugreift, würde man die Umwandlung direkt beim Setter machen.

[himitsu]

Jupp, statt einer Get-Methode und vielleicht auch noch einer setWert1AsReal, lässt sich ein Property bestimmt intuitiver nutzen.

Vor allem wenn man bedenkt, wo man noch alles etwas einsparen/kombinieren/vereinheitlichen kann.

Delphi-Quellcode:

type
  TTest = class
  private
    function GetWertAsReal(Index: Integer): Real;
    procedure SetWertAsReal(Index: Integer; Value: Real);
  public
    //Werte: array[1..2] of String;
    Wert1: String;
    Wert2: String;
    property Wert1AsReal: Real index 1 read GetWertAsReal write SetWertAsReal;
    property Wert2AsReal: Real index 2 read GetWertAsReal write SetWertAsReal;

    property WertAsReal[Index: Integer]: Real read GetWertAsReal write SetWertAsReal; // hier im Getter/Setter die Bereichsprüfung nicht vergessen
  end;

procedure TTest.GetWertAsReal(Index: Integer): Real;
{
begin
  Result := wandleStringZuReal(Werte[Index]);
end;
}
var
  S: String;
begin
  case Index of
    1: S := Wert1;
    2: S := Wert2;
  end;
  Result := wandleStringZuReal(S);
end;
{
begin
  case Index of
    1: Result := wandleStringZuReal(Wert1);
    2: Result := wandleStringZuReal(Wert2);
    else Result := 0; // wegen Compilerwarnung
  end;
end; 
}

[Chris30]

Guten Morgen,

erstmal vielen Dank an alle die bisher geantwortet haben.
Eine Frage zu Properties hätte ich jetzt noch.

Nutzt man diese um intuitiver arbeiten zu können?
Oder gibt es noch andere unterschiede zu Standard getter und setter Methoden wie man sie vielleicht aus Java kennt?

[freimatz]

Zitat von Chris30:

Sollte man grundsätzlich proceduren/function vermeiden die kürzer als ~5 Zeilen sind?

Nein

Wenn es eine Aufgabe gibt, die für sich abgeschlossen ist, dann mache ich auch schon Methoden die nur eine Zeile enthalten.

Das Gegenteil ist oft der Fall. Man sollte Methoden vermeiden die länger als 5 Zeilen sind.
Ok, 5 ist ein bischen krass, aber spätestens wenn die Methode nicht ganz auf den Bildschirm passt ist es zuviel.

Aber ich finde es gut, dass Du Dir Gedanken über sowas machst. Viele basteln einfach drauflos.

[Aviator]

Ich erstelle z.B. dann eine neue Methode, wenn ich Code mehrfach benötige und ihn dann doppelt schreiben müsste. Wenn er nicht 100%ig identisch ist, das aber mit einem Parameter wiederum gelöst werden kann, dann wird der Methodenaufruf eben entsprechend angepasst.

Und ja, Methoden haben bei mir oft auch nur eine Zeile wenn es Helper Methoden sind oder Werte aus einer definierten Quelle zurückgegeben werden müssen (die vielleicht auch noch berechnet werden oder so). Overload Methoden sind auch so ein Beispiel. Die Methode ruft eine gleichnamige andere Methode auf, übergibt aber einen festen Parameter.

[DeddyH]

Zitat von Aviator:

Ich erstelle z.B. dann eine neue Methode, wenn ich Code mehrfach benötige und ihn dann doppelt schreiben müsste. Wenn er nicht 100%ig identisch ist, das aber mit einem Parameter wiederum gelöst werden kann, dann wird der Methodenaufruf eben entsprechend angepasst.

Same here, für mich hat sich diese Vorgehensweise bewährt. Eine weitere Möglichkeit sind noch Overloads, solange das dann nicht zu viele werden.

[dummzeuch]

Zitat von Chris30:

Eine Frage zu Properties hätte ich jetzt noch.

Nutzt man diese um intuitiver arbeiten zu können?
Oder gibt es noch andere unterschiede zu Standard getter und setter Methoden wie man sie vielleicht aus Java kennt?

Properties können noch als published deklariert werden, dann kann man per Runtime Type Information (RTTI) darauf zugreifen. Neuere Delphis können das auch für nicht-published Properties.

Aber das geht jetzt deutlch über die normale Verwendung von Properties hinaus.

Anders als bei Java kann aber eine Property auch direkt auf ein Feld verweisen oder ein Feld direkt lesen aber per Setter-Methode schreiben:

Delphi-Quellcode:

type
  TMyClass
  private
    FMyField: integer;
    procedure SetMyField(_Value: integer);
  public
    property MyField: integer read FMyField write SetMyField;
  end;

Ach ja, dann gibt es noch Array-Properties:

Delphi-Quellcode:

type
  TMyClass
  private
    function GetMyProperty(_Idx: integer): string;
    procedure SetMyProperty(_Idx: integer, const _Value: string);
  public
    property MyProperty[_Idx: integer]: string read GetMyProeprty write SetMyProperty;

Eine solche Array-Property kann auch noch als default deklariert werden, so das man beim Zugriff den Namen weglassen kann. Das wird z.B. bei TStringList verwendet, eigentlich muesste man da auf die Items-Property zugreifen, es geht aber auch so:

Delphi-Quellcode:

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  sl.Add('bla');
  WriteLn(sl[0]);
  WriteLn(sl.Items[0]);