Class Helper for Interface

[himitsu]

Bei der Vererbung müssen sich aber die Helper kennen, bzw. es sind dann "immer" beide Helper eingebunden, wenn man den Nachfahren haben will.


Man kann aber nicht mehrere Helper unabhängig "parallel" deklarieren.
z.B. der Helper vom Delphi, dann Meiner (OK, da könnte man vererben), aber jetzt kommen noch die Helper von sh17 und Anderen dazu, die ich mir über Fremdkomponenten reinhole.

Sollen wir uns jetzt alle einigen, wer von wem erbt?
Vererbung ist keine Lösung, denn gerade diese Abhängigkeiten wollte man doch loswerden. Da könnte man die Class-Helper auch gleich wegwerfen und direkt die Klassen-Vererbung benutzen.

[Der schöne Günther]

Es würde immerhin reichen, dem RTL-eigenen TStringHelper (und Konsorten) noch etwas eigenes hinzuzufügen. Wenigstens einmal. Ich bin ein genügsamer Mensch.

[TiGü]

Zitat von Stevie:

Zitat von Dejan Vu:

Preisfrage: Wo ist 'Bar' denn implementiert? Im Interface sicherlich nicht...

Delphi-Quellcode:

IFooHelper = interface helper for IFoo
  procedure Bar;
end;

ist equivalent zu:

procedure Bar(const Self: IFoo);

Aber muss das Objekt dann nicht trotzdem IFooHelper kennen?
Wie soll das sonst funktionieren?

[Stevie]

Zitat von himitsu:

Bei der Vererbung müssen sich aber die Helper kennen, bzw. es sind dann "immer" beide Helper eingebunden, wenn man den Nachfahren haben will.


Man kann aber nicht mehrere Helper unabhängig "parallel" deklarieren.
z.B. der Helper vom Delphi, dann Meiner (OK, da könnte man vererben), aber jetzt kommen noch die Helper von sh17 und Anderen dazu, die ich mir über Fremdkomponenten reinhole.

Sollen wir uns jetzt alle einigen, wer von wem erbt?
Vererbung ist keine Lösung. Da könnte man die Class-Helper auch gleich wegwerfen und direkt die Klassen-Vererbung benutzen.

Ich hab nur gesagt, wie es ist, nicht dass es gut ist. Vererbung von helpern ist Unfug. Sie sollten es vernünftig (oh je) implementieren und mehrere erlauben und korrekt erkennen, wenn es Konflikte gibt - oder den klassischen Weg von "wenn es 2 gleiche gibt, dann überdeckt der letzte den vorherigen" - wobei ich dieses Verhalten von Delphi schon seit jeher als sehr gefährlich betrachte.

Zitat von TiGü:

Aber muss das Objekt dann nicht trotzdem IFooHelper kennen?
Wie soll das sonst funktionieren?

Was hat das Objekt damit zu tun? Ich operiere auf dem Interface, wo is da nen Objekt?

[TiGü]

Zitat von himitsu:

Man kann aber nicht mehrere Helper unabhängig "parallel" deklarieren.
z.B. der Helper vom Delphi, dann Meiner (OK, da könnte man vererben), aber jetzt kommen noch die Helper von sh17 und Anderen dazu, die ich mir über Fremdkomponenten reinhole.

Und bei gleichen Methoden (Bezeichner und Rückgabewert) in den Helpern?
Wie soll das Problem gelöst werden, welche Methode genommen werden soll? Mit As-Operator?

[TiGü]

Zitat von Stevie:

Zitat von TiGü:

Aber muss das Objekt dann nicht trotzdem IFooHelper kennen?
Wie soll das sonst funktionieren?

Was hat das Objekt damit zu tun? Ich operiere auf dem Interface, wo is da nen Objekt?

Muss nicht irgendwer irgendwann mal irgendwas implementieren?

[himitsu]

Zitat von TiGü:

Und bei gleichen Methoden (Bezeichner und Rückgabewert) in den Helpern?

Siehe Stevies Antwort, kurz vor dir.


Auch Interfaces kann man vererben, aber dann muß ich die Methoden nicht nur ins Interface einbauen, sondern auch in das dahinterliegende Objekt und genau das kann/will ich nicht, vorallem nicht, wenn man das Dahinter garnicht kennt und keinen Zugriff darauf hat.

Mir würde es auch reichen, wenn man statische Methoden direkt im Interface deklarieren könnte, aber weil das nicht geht, dachte ich, ich probiere es einfach mal mit einem Helper, der dann auch garnicht ging.

[himitsu]

Zitat von TiGü:

Muss nicht irgendwer irgendwann mal irgendwas implementieren?

Der Code steckt im Helper, so wie jetzt auch, bei all den anderen Helpern.

Das Objekt/Interface muß und soll garnichts davon wissen, genauso wie der Vorfahr von einer Vererbung auch nichts wissen soll.
Der Compiler leitet den Aufuf auf die Helper-Methode um, wenn er sie findet und geht nicht direkt auf das Objekt/Interface los.

[add]
Das ist es, was Delphi bei den Class-Helpern macht ... so im Prinzip.

Delphi-Quellcode:

type
  TMyClass = class
    procedure Foo(S: string);
  end;
  TMyDummyClassHelper = class(TMyClass)
    procedure Bar(S: string);
  end;

procedure TMyClass.Foo(S: string);
begin
  ShowMessage(S);
end;

procedure TMyDummyClassHelper.Bar(S: string);
begin
  S := StringReplace(S, ' ', ' du schöne ', []);
  Foo(S);
end;

var
  C: TMyClass;
begin
  C := TMyClass.Create;
  C.Foo('Hallo Welt!');
  //C.Bar('Hallo Welt!');  << Compiler findet Bar im Helper und baut quasi einen Cast ein.
  TMyDummyClassHelper(C).Bar('Hallo Welt!');
end;

Das haben die einfach so von mir abgeguckt, denn sowas hatte ich früher schon gemacht, als es noch keine Helper gab.

[Dejan Vu]

Zitat von himitsu:

Die Funktion ist eben nicht im Interface, genauso wenig, wie bei den anderen Record/Class-Helpern oder so wie eine class procedure nicht im Objekt steckt, zu Welchem sie deklariert wurde.

[TiGü]

So einfach kann es manchmal sein, wenn man kein Brett vorm Kopf hat!

Spricht denn irgendwas rein technisch gegen Interface-Helper?
COM-Kompatibilität oder so?