Idee Zur Synchronisation eines Interfaces mit Klasse (mit MMX?)

[HeZa]

Hallo

da Uwe ja mal nach Feature Vorschlägen zum MMX gefragt hat möchte ich jetzt gerne einen los werden:

Motivation
Die Synchronisation zwischen einem Interface und einer implementierenden Klasse ist irgendwie nervig und selbst dass was ich an Tool-Unterstützung gesehen (und verstanden habe?) überzeugt mich nicht.

Wie ich es mir vorstelle würde

Ein Beispiel mit einer Unit für das Interface und einer für die Klasse (wichtig sind die speziellen Kommentare).

Zuerst lege ich die Interface-Unit an:

Delphi-Quellcode:

unit DTO.Person.Intf;

interface

type
  IPerson = interface {!MMX: implemented by TPerson in DTO.Person.Impl}
  ['{1D826CBD-244A-4D1C-ADCC-C1AB8FAB36B2}']
  end;

implementation

end.

Dann die Klassen-Unit:

Delphi-Quellcode:

unit DTO.Person.Impl;

interface

uses
  DTO.Person.Intf;

function NewPerson: IPerson;

implementation

type
  TPerson = class(TInterfacedObject, {!MMX: implements in DTO.Person.Intf } IPerson )
  private
    FAge: Integer;
    procedure CheckData;
    function GetName: string;
    procedure SetAge(const Value: Integer);
    procedure SetName(const Value: string);
  public
    constructor Create;
    destructor Destroy; override;
    function YearOfBirth: integer;
    property Name: string read GetName write SetName;
    property Age: Integer read FAge write SetAge;
  end;

{ method implementation here ... }

end.

Befinde ich mich in der Interface oder Klassen Deklaration kann ich über einen Short Cut (z.B. Shift+Ctrl+I) eine Synchronisation auslösen.
Voraussetzung dafür wäre der jeweilige Kommentar mit dem MMX Start-Code {!MMX: ... }.

Dann wird die aktuelle Interface Methodenlist verworfen und aus der Klasse neu aufgebaut und zwar nach folgenden Regeln:

• Nimm alle Methoden und Properties mit den Sichtbarkeiten Public, Publisched oder Auto.
• Lasse alle Konstruktoren und Destruktoren weg.
• Lasse alle Properties weg die sich bei read oder write auf ein Klassenfeld beziehen.
• Referenziet ein Property bei read oder write eine Methode mit einer geringeren Sichtbarkeit übernehme auch diese.

Das Interface würde anschließend wir folg aussehen:

Delphi-Quellcode:

unit DTO.Person.Intf;

interface

type
  IPerson = interface {!MMX: implemented by TPerson in DTO.Person.Impl}
  ['{1D826CBD-244A-4D1C-ADCC-C1AB8FAB36B2}']
    function GetName: string;
    procedure SetName(const Value: string);
    function YearOfBirth: integer;
    property Name: string read GetName write SetName;
  end;

implementation

end.

Die Syntax für die Kommentarzeilen wäre

• für das Interface (muss hinter dem Interface-Header stehen)
  {!MMX: implemented by <ClassType> [in <UnitName>] }
• für die Klasse (muss vor dem zu implementierenden Interface stehen)
  {!MMX: implements [in <UnitName>] }

Was ist eure Meinung dazu (Vielleicht ist es ja auch einfach nur die Hitze )?

Ciao Heinz Z.

[Uwe Raabe]

Erst einmal Danke für den Vorschlag.

Bezüglich der Implementierung mit MMX gibt es aber ein sehr wesentliches Hindernis: MMX manipuliert bislang ausschließlich die aktuelle Unit, was deiner Vorgabe

Zitat:

Ein Beispiel mit einer Unit für das Interface und einer für die Klasse

widersprechen würde.

Auch habe ich so meine Probleme mit der strikten 1:1 Kopplung zwischen Interface und Klasse. Das ist ja nun wirklich nicht der generelle Fall. Sowohl ist es nicht unüblich, mehrere implementierende Klassen zu haben, als auch kann eine Klasse mehrere Interfaces implementieren. Hier müsste also in jedem Fall eine gezielte Anwahl des Interfaces und der Klasse bzw. eine Selektion der Methoden/Properties der Klasse und des Interfaces als Ziel möglich sein.

Lassen wir nun noch die Multi-Unit Bedingung außen vor und sehen, was mit den Bordmitteln schon zu erreichen ist.

Für den Weg Klasse -> Interface käme wohl am ehesten die Funktion Extract Interface in Frage. Hier werden in einer Klasse die gewünschten Methoden und Properties selektiert und in ein neues Interface in der aktuellen Unit extrahiert. Das bestehende Interface müsste man vorher manuell löschen, wobei dies eventuell noch automatisierbar wäre (eine Meldung kommt ja eh schon, wenn das Interface bereits existiert). Wenn es nur um das Hinzufügen neuer Methoden zu dem Interface geht, lässt sich das auch relativ einfach per Drag'n'Drop bzw. Copy/Paste erledigen.

Für den anderen Weg Interface -> Klasse ist ja der Interface Wizard zuständig, der bereits das gewünschte Verhalten weitestgehend realisiert, wenn man das Interface auf die Klasse zieht. Bei entsprechender Einstellung geschieht das auch ohne daß der Dialog aufpoppt.

Sicher sehe ich für dein Beispiel eine ziemliche Arbeitsersparnis durch eine solche Funktionalität. Ich fürchte nur, daß der Anwendungsfall etwas zu speziell ist und sich nicht so einfach generalisieren lässt. Nichtsdestotrotz würde ich eine rege Diskussion zu diesem Thema hier sehr begrüßen.

[Fritzew]

Und wenn das Interface in 50 Klassen implementiert wird?
Vielleicht habe ich mich ja nur daran gewöhnt,
aber wenn es eine Änderung im Interface gibt muss ich mir die Klassen ja sowieso anschauen.
Dann DragDrop des Interfaces auf die Klasse........

Rot aber trotzdem abgeschickt.....

[HeZa]

Okay, ich habe öfters den Anwendungsfall das ich zu einem Interface genau eine Klasse habe, nämlich immer dann wenn ich mich bei der Verwendung meiner Klasse nicht um die Freigabe kümmern möchte oder das Objekt eben sollange Leben soll, bis es keiner mehr verwendet. Da kann das Interface auch gerne in der gleichen Unit liegen.

[mkinzler]

Das ist aber nicht der Standard.

[stahli]

Ich will die Gelegenheit mal nutzen und nochmal auf mein Tool aufmerksam machen: https://www.delphipraxis.net/196493-unitoptimizer.html
Bis jetzt gab es da ja noch keine überwältigende Resonanz, aber vielleicht kommt das ja noch...

Ich finde das jedenfalls den einfachsten und übersichtlichsten Ansatz und werde das auch weiter umsetzen (momentan muss ich mich nur erst mal um meine Website und DSGVO kümmern).
Danach arbeite ich aber weiter an dem Tool und werde es auch selbst einsetzen und testen (habe es ja angefangen, weil ich eine solche Lösung gesucht hatte).