Eine Art umgekehrte Prozedur

[Popov]

Delphi-Quellcode:

function Test1(x: Integer): Integer;
begin
  Result := 10; //Stellvertretend für viel Code

  Result := Result * x; //<<<<<< Nur diese Zeile ist anderes <<<<<<

  Result := Result * 10; //Stellvertretend für viel Code
end;

function Test2(y: Integer; s: String): Integer;
begin
  Result := 10; //Stellvertretend für viel Code

  Result := Result * x + StrToInt(s); //<<<<<< Nur diese Zeile ist anderes <<<<<<

  Result := Result * 10; //Stellvertretend für viel Code
end;

In der Regel ist es so: man hat einen Code der sich wiederholt und der immer wieder genutzt wird, also lagert man das in eine Prozedur oder Funktion aus und greift dann auf die zurück.

Nun habe ich aber ein anderes Problem. Ich habe x Prozeduren die fast identisch sind, nur in der Mitte unterscheiden sich (sagen wir mal) zwei Code-Zeilen.

Hier ist das Problem verdreht. In der Regel ist der innere Teil gleich, also lagert man es aus. Hier ist es umgekehrt. Hier ist der äußere Teil gleich, nur der Innere anders.

If-Abfragen oder Case bringen hier nichts, denn die Parameter sind immer unterschiedlich. Nun könnte man den Vorderen Teil in eine Prozedur auslagern, den hinteren Teil in eine andere. Das würde gehen, aber irgendwie gehören beide Teile zusammen. Vor allem werden lokale Variablen und Objekte genutzt, was es etwas kompliziert macht es aufzuteilen.

Gibt es also die Möglichkeit den äußeren Teil auszulagern und dann den inneren darin auszuführen?

[Valle]

Vielleicht sowas wie ein Callback? Du übergibst einen Methodenpointer, der dann tut was er soll.

Oder du implementierst das mit Klassen. Abstrakte Basisklasse ruft Methode auf, die erst implementiert werden soll. (Schablonenmethode)

[Uwe Raabe]

In meinem Delphi würde ich das mit einer Anonymen Methode lösen...

[Sir Rufo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1295401)

In meinem Delphi würde ich das mit einer Anonymen Methode lösen...

Dazu fehlen Popov allerdings ein X und ein E in der Delphi-Version ... sonst wäre das der richtige Tip.

[himitsu]

Wobei eine anonyme Methode auch "nur" ein Callback ist.

PS: Man kann natürlich auch den vielen Code in zwei Methoden/Prozeduren auslagen und dann überall aufrufen. :stupid:

[BUG]

Zitat:

Zitat von Popov (Beitrag 1295396)

If-Abfragen oder Case bringen hier nichts, denn die Parameter sind immer unterschiedlich.

Das wurde hier bisher noch nicht beachtet.

Ich sehe 2 mögliche Lösungsansätze:

• Übergebe der umschließenden Funktion ein Callback-Objekt abgeleitet von einer gemeinsamen Basisklasse. Dieses kapselt den inneren Aufruf und die dafür nötigen Argumente.
• Spalte die umschließende Funktion in 2 Methoden auf; die lokalen Variablen kannst du dann in Member umwandeln. Im Destruktor nicht vergessen aufzuräumen sollte zwischendurch irgendwas schiefgehen :wink:

[Thomasl]

Eine ganz andere aber einfache Möglichkeit ist, den gleichen teil in eine IncludeDatei zu packen

Delphi-Quellcode:

function Test1(x: Integer): Integer;
begin
  {$I aaa.inc}
  Result := Result * x; //<<<<<< Nur diese Zeile ist anderes <<<<<<
  {$I bbb.inc}
end;

function Test2(y: Integer; s: String): Integer;
begin
  {$I aaa.inc}
  Result := Result * x + StrToInt(s); //<<<<<< Nur diese Zeile ist anderes <<<<<<
  {$I bbb.inc}
end;

aaa.inc

Code:

Result := 10; //Stellvertretend für viel Code

bbb.inc

Code:

Result := Result * 10; //Stellvertretend für viel Code

[stahli]

Include-Dateien lassen sich allerdings schlechter (oder gar nicht? - ich weiß nicht mehr genau) debuggen.

[Popov]

Evtl. werde ich versuchen es mit einer Callback-Funktion zu lösen. Muss klein wenig experimentieren.

[Thomasl]

Debuggen geht genauso.
aber das suchen, öffnen dahin springen ist beschissen.

Das ist ja nur eine mögliche Lösung unter vielen

[Bjoerk]

Wie wärs mit einem Flag?

Delphi-Quellcode:

TMachWasFlag = (mwfNone, mwfDoSomething, mwfDoSomethingElse, ..);

function MachWas( .. ; Flag: TMachWasFlag): Integer;
begin
  Result := 10; //Stellvertretend für viel Code
  case Flag of
    mwfDoSomething:
      Result := DoSomething(..);
    mwfDoSomethingElse:
      Result := DoSomethingElse(..);
    ..
  else
    Result := ..
  end;
  Result := Result * 10; //Stellvertretend für viel Code
end;

Falls Die Liste der Parameter sehr unterschiedlich ist, ist dieses Design aber nicht zu empfehlen.

[Dejan Vu]

Unter OOP-Gesichtspunkten ist dieses Design auch nicht zu empfehlen.

Falls der Fragesteller etwas mit OOP im Sinn hat, würde ich zur Schablonenmethodenmuster raten, wie von Valle hier schon empfohlen wurde.

Wenn OOP gar nicht geht, könnte man noch Prozedurvariablen und Enums ins Spiel bringen:

Delphi-Quellcode:

Type
  TFunction = Function (p : Integer) : Integer;

Var
  SpecialFunc : Array [TMachWasFlag] of TFunction;

function DoSomething (p : Integer) : Integer; begin result := p + 1 end;
function DoSomethingElse (p : Integer) : Integer; begin result := p + 10 end;

function MachWas( .. ; Flag: TMachWasFlag): Integer;
begin
   Result := 10; //Stellvertretend für viel Code

   Result := SpecialFunc(Flag);

   Result := Result * 10; //Stellvertretend für viel Code
end;

procedure InitSpecialFunc;
Begin
  SpecialFunc[mwfDoSomething] := DoSomething;
  SpecialFunc[mwfDoSomethingElse] := DoSomethingElse;
End;

... InitSpecialFunc;

  MachWas(...

"Vorteil": OCP in Ansätzen umgesetzt.

[Thomas_K]

Ja das Problem ist auch mir vertraut man hat eine Funktion und muss diese erweitern, was aber nicht wirklich gut geht. Ein Lösungsansatz wäre irgendwelche Flags als Globalevariable zubenutzen, doch damit geht die Codequalität sicherlich den Bach runter. Besser aus meiner Sicht, man schreibt eine Klasse, so dass man mit Objekte arbeiten kann, die man über Properties erweitert oder besser durch Ableitungen anpasst, also Ändern nur durch erweitern. Damit brauch man nicht permanent „alten“ Code dauern umstellen, wenn man etwas Neues ausprobieren Möchte. Der Code kann übersichtlicher werden, man muss dafür am Anfang etwas mehr Zeit investieren wo von später aber profitiert.

Code:

type 
  TBasisFunktion = class
  protected
    FCommonResult: TCommonResult
    procedure Basic(ParamterXY);
  end;
 
type
  TStandardVariante = class(TBasisFunktion)
  public
    function StandardVariante(..):..
  end:
  
type
  TErweiterteVariante = class(TBasisFunktion)
  public
    function ErweiterteVariante(..):..
  end:

[Dejan Vu]

Und wer ruft 'StandardVariante' und 'ErweiterteVariante' auf?

[Bjoerk]

Zitat:

Zitat von Dejan Vu (Beitrag 1295469)

"Vorteil": OCP in Ansätzen umgesetzt.

Nachteil: Du hast #1 nicht gelesen. :wink: "die Parameter sind immer unterschiedlich"