Interface aus bestehenden Klassen erstellen

[fisipjm]

Hi in die Runde,

ich bin schon seit einiger Zeit Delphi entwickler und möchste meine Fähigkeiten in der Programmierung verbessern und erweitern. Lese aktuell die Bücher von Nick Hodges, kann ich auf diesem weg nur empfehlen.
Zukünfitg will ich meine Enwticklungen immer mit unit Tests ausstatten. Dafür muss ich zukünftig zwangsläufig mit interfaces arbeiten. Mein erster Schritt den ich jeztz machen wollte, war es ein Interface für das laden von lokalen Einstellungen zu erstellen. Also sowas wie:

Delphi-Quellcode:

unit LocalSettingsInterface;

interface

type
  ILocalSetttings = interface
    ['{BAAEC9A9-5D37-48C7-9A60-3AABE21845B7}']
    procedure writeString(const value: string);
    function readString: string;
    procedure writeInteger(value: Integer);
    function readInteger: Integer;
  end;

implementation

end.

Da ich aber eigentlich so gut wie immer die Delphi eigenen klassen verwende, sowas wie Tinifile oder TRegistry, kann ich diese ja nicht von einem IInterfacedObject ableiten. WIe stell ich das an, für bestehende Klassen ein Interface zu erstellen? Oder muss ich immer eine eigene KLassenableitung erstellen? Ich hoffe die Frage ist nicht zu Kindergarten, aber meine bisherige Websuche hat mich irgenwie nicht wirklich schlauer gemacht

Gruß
PJM

[dummzeuch]

Zitat von fisipjm:

Da ich aber eigentlich so gut wie immer die Delphi eigenen klassen verwende, sowas wie Tinifile oder TRegistry, kann ich diese ja nicht von einem IInterfacedObject ableiten. WIe stell ich das an, für bestehende Klassen ein Interface zu erstellen? Oder muss ich immer eine eigene KLassenableitung erstellen? Ich hoffe die Frage ist nicht zu Kindergarten, aber meine bisherige Websuche hat mich irgenwie nicht wirklich schlauer gemacht

Dazu habe ich vor vielen Jahren mal was geblogt:

Zitat:

Die Alternative könnte wie folgt aussehen:

Man deklariere eine von TInterfacedObject abgeleitete Wrapper-Klasse, welche die lästige Basisimplementation von IUnknown übernimmt und die darüber hinausgehende Implementation von ISomeInterface an TSomeClass delegiert:

Delphi-Quellcode:

type
  TSomeWrapper = class(TInterfacedObject, ISomeInterface)
  protected
    fSomeClass: TSomeClass;
    property SomeClass: TSomeClass read fSomeClass implements ISomeInterface;
  public
    constructor Create(_SomeClass: TSomeClass);
    destructor Destroy; override;
  end;

...

constructor TSomeWrapper.Create(_SomeClass: TSomeClass);
begin
  inherited Create;
  fSomeClass := _SomeClass;
end;

destructor TSomeWrapper.Destroy;
begin
  fSomeClass.Free;
  inherited;
end;

Benutzt wird dieses Objekt wie folgt:

Delphi-Quellcode:

var
  SomeInt: ISomeInterface;
...
  SomeInt := TSomeWmapper.Create(TSomeClass.Create);
  SomeInt.Method1;
...

Man erzeugt also eine Instanz von TSomeWrapper, übergibt ihr eine ebenfalls frisch erzeugte Instanz von TSomeClass, und verwendet sie als ob es sich um eine auf magische Weise auch von TInterfacedObject abgeleitete Version von TSomeClass handelte, weist sie z.B. auf eine Variable vom Typ ISomeInterface zu. Reference-Counting natürlich inklusive.

http://www.dummzeuch.de/delphi/objec...%20L%C3%B6sung

[himitsu]

"Eine" Klasse kann mehrere Interfaces implementieren.
mit bissl gefummel geht es sogar, wenn das Interfaces mit gleichnamigen Methoden sind. (es ist möglich quasi den Methodenname vom Interface in der Klasse anders zu bennennen, falls es konflikte gibt)
class TYourClass = class(TYourBase, IInterface1, IInterface2, ...)

Man kann Interfaces auch voneinander ableiten, also z.B. die zweite Version eines Interfaces (mit neuen Methoden), aber wo die Alten auch drin sind,

[fisipjm]

Zitat von himitsu:

"Eine" Klasse kann mehrere Interfaces implementieren.
mit bissl gefummel geht es sogar, wenn das Interfaces mit gleichnamigen Methoden sind. (es ist möglich quasi den Methodenname vom Interface in der Klasse anders zu bennennen, falls es konflikte gibt)
class TYourClass = class(TYourBase, IInterface1, IInterface2, ...)

Man kann Interfaces auch voneinander ableiten, also z.B. die zweite Version eines Interfaces (mit neuen Methoden), aber wo die Alten auch drin sind,

Hey Himitsu,
danke für deine Antwort, dann müsste ich mir aber immer wie in der Frage schon dangedeutet eine eigene Klasse ableiten. Und dann logischerweise auch die Interface deklaration mit der ageleiteten Klasse und nicht der Basisklasse machen. Das würde ich gern umgehen

Danke aber für den Code, jedes bisschen hilft beim lernen.

[fisipjm]

Zitat von dummzeuch:

Zitat von fisipjm:

Da ich aber eigentlich so gut wie immer die Delphi eigenen klassen verwende, sowas wie Tinifile oder TRegistry, kann ich diese ja nicht von einem IInterfacedObject ableiten. WIe stell ich das an, für bestehende Klassen ein Interface zu erstellen? Oder muss ich immer eine eigene KLassenableitung erstellen? Ich hoffe die Frage ist nicht zu Kindergarten, aber meine bisherige Websuche hat mich irgenwie nicht wirklich schlauer gemacht

Dazu habe ich vor vielen Jahren mal was geblogt:

Zitat:

Die Alternative könnte wie folgt aussehen:

Man deklariere eine von TInterfacedObject abgeleitete Wrapper-Klasse, welche die lästige Basisimplementation von IUnknown übernimmt und die darüber hinausgehende Implementation von ISomeInterface an TSomeClass delegiert:

Delphi-Quellcode:

type
  TSomeWrapper = class(TInterfacedObject, ISomeInterface)
  protected
    fSomeClass: TSomeClass;
    property SomeClass: TSomeClass read fSomeClass implements ISomeInterface;
  public
    constructor Create(_SomeClass: TSomeClass);
    destructor Destroy; override;
  end;

...

constructor TSomeWrapper.Create(_SomeClass: TSomeClass);
begin
  inherited Create;
  fSomeClass := _SomeClass;
end;

destructor TSomeWrapper.Destroy;
begin
  fSomeClass.Free;
  inherited;
end;

Benutzt wird dieses Objekt wie folgt:

Delphi-Quellcode:

var
  SomeInt: ISomeInterface;
...
  SomeInt := TSomeWmapper.Create(TSomeClass.Create);
  SomeInt.Method1;
...

Man erzeugt also eine Instanz von TSomeWrapper, übergibt ihr eine ebenfalls frisch erzeugte Instanz von TSomeClass, und verwendet sie als ob es sich um eine auf magische Weise auch von TInterfacedObject abgeleitete Version von TSomeClass handelte, weist sie z.B. auf eine Variable vom Typ ISomeInterface zu. Reference-Counting natürlich inklusive.

http://www.dummzeuch.de/delphi/objec...%20L%C3%B6sung

Hey Dumuzeuch,

das ist ja echt schon ewig her. Da sieht man mal was es alles aufzuholen gilt
Deine Lösung gefällt mir gut, ich versuch mal mein Glück. Danke!

[himitsu]

Jupp, ableiten.
Dann bleibt nur noch der Wrapper drumrum.

Viele Klassen haben zwar bereits ein "Interface" drin (z.B. alles was von TPersistent/TComponent abgeleitet ist),
aber das, was du wissen willst, würde dort wohl fehlen.

[peterbelow]

Zitat von fisipjm:

Hi in die Runde,


Zukünfitg will ich meine Enwticklungen immer mit unit Tests ausstatten. Dafür muss ich zukünftig zwangsläufig mit interfaces arbeiten.

Wieso? Mit DUnit kann man Testcases für Klassen, Interfaces, standalone Procedures etc. erstellen. Test-driven Deverlopment ist in keiner Weise an die Verwendung von Interfaces gekoppelt.

[TurboMagic]

Hallo,

ja, es ist nicht daran gekoppelt. Aber wenn man Dinge Mocken können will oder so,
dann ist es sicher praktischer wenn sich die Unit Tests auf ein Interface beziehen.
Schlage vor, du liest mal Nick Hodges' Bücher, dann merkst du auf was der OP hinaus
will...

Grüße
TurboMagic

[freimatz]

Zitat von fisipjm:

ich bin schon seit einiger Zeit Delphi entwickler und möchste meine Fähigkeiten in der Programmierung verbessern und erweitern. Lese aktuell die Bücher von Nick Hodges, kann ich auf diesem weg nur empfehlen.
Zukünfitg will ich meine Enwticklungen immer mit unit Tests ausstatten.

Zitat von fisipjm:

Ich hoffe die Frage ist nicht zu Kindergarten, ...

Leider Ja. Ich wünschte es wäre bei Delphi-Entwickler normal dass man e sso macht. Außerhalb Delphi ist eine solche Programmierweise schon lange bekannt. (https://clean-code-developer.de)

[TurboMagic]

Hilfreich wäre es aber auch, wenn die IDE eine Liste aller Klassen im Projekt, die ein bestimmtes Interface implementieren, ausspucken könnte
und von dort könnte man gleich zur passenden Klassendeklaration springen...