Interface-Unterstützung

[stahli]

Ich arbeite viel mit Interfaces. Mich nervt, dass die IDE (m.E.) das kaum unterstützt.
So muss man redundant und wiederholt ständig das gleiche schreiben und man findet die Methoden nicht vernünftig in der Unit, da diese beliebig einsortiert werden.

Also folgendes Beispiel mit anschließender Erklärung...


UnitMyIntf.pas

Delphi-Quellcode:

IMyIntf1 = Interfaces
  property MyProp1: string read write;
  procedure Do1(P: string);
end;

IMyIntf2 = Interfaces
  property MyProp2: string read;
  procedure Do2(P: string);
end;

UnitMyClass.pas

Delphi-Quellcode:

TMyClass = class(TInterfacedObject, IMyIntf1, IMyIntf2)
protected { IMyIntf1 }
  fMyProp1: string;
  function _get_MyProp1: string;
  procedure _set_MyProp1(Value: string);
protected { IMyIntf2 }
  fMyProp2: string;  
  function _get_MyProp2: string;
public
  constructor Create; virtual;
  destructor Destroy; override;
public { IMyIntf1 }
  property MyProp1: string read _get_MyProp1 write _set_MyProp1;
  procedure Do1(P: string);
public { IMyIntf2 }
  property MyProp2: string read _get_MyProp2;
  procedure Do2(P: string);
end;

...

{ TMyClass }

constructor TMyClass.Create;
begin
end;

destructor TMyClass.Destroy;
begin
  inherited;
end;

{ TMyClass / IMyIntf1 }

function TMyClass._get_MyProp1: string;
begin
  Result := fMyProp1;
end;

procedure TMyClass._set_MyProp1(Value: string);
begin
  fMyProp1 := Value;
end;

procedure TMyClass.Do1(P: string);
begin
end;

{ TMyClass / IMyIntf2 }

function TMyClass._get_MyProp2: string;
begin
  Result := fMyProp2;
end;

procedure TMyClass.Do2(P: string);
begin
end;

Ich hätte gern folgende Aspekte:

1) Im Interface möchte ich die Getter und Setter nicht komplett definieren müssen. Dies würde die Sache vereinfachen und die Übersichtlichkeit erhöhen.
Der Compiler könnte ja eigentlich - wenn dort "read" und/oder "write" steht, einfach "gedanklich" Standardgetter und -setter voraussetzen.

2) In den Klassen hätte ich gern die Abschnitte, die Interfaces zugewiesen sind, entsprechend geordnet und beschrieben.
Im Implementationsteil sollte das entsprechend gehandhabt werden. Zunächst sollten Constructor und Destructor kommen, dann die normalen Methoden und dann die Interface-Methoden mit entsprechender Gliederung und Sortierung.

3) Sofern in den Interfaces Getter und Setter definiert sind und diese in den Klassen erstmalig erzeugt werden, sollten auch gleich private Felder "fMyProp: MyType;" eingerichtet und in den Gettern und Settern benutzt werden. Da ist ja bestimmt zu 95% der Normalfall und mich nervt, dass man das jedesmal neu von Hand machen muss (zumal Getter und Setter ja wild in der Unit verteilt sind).

4) Refactoring von Interfaces zu Klassen sollte möglich sein. Wenn ich z.B.
procedure Do1(P: string); im Interface ändere in
procedure Do1(const aValue: string); sollte das auch in die Klassendeklarationen übertragbar sein, die dieses Interface verwenden (im Interface- und Implementationsteil).
Die Methoden können dann zwar ggf. nicht kompiliert werden, aber ich brauch nur noch die logischen Dinge anpassen und bin sicher, dass die Änderungen im Interface (z.B. Propertynamen) auch in den Klassen angepasst wird.


Ich wüsste mal gern Eure Meinung dazu.
Haltet Ihr die Überlegungen für sinnvoll/wichtig?
Gibt es dazu vielleicht schon Möglichkeiten, die ich bisher übersehen habe (Ich würde mich in den A... beißen und davon ein Foto hochladen )).

Hättet Ihr (die Ihr mit Interfaces arbeitet) Interesse an so einer Lösung?

Auf Emba setze ich diesbezüglich leider nicht. Wenn diese Dinge demnächst richtig gut unterstützt würden, dann würde ich sogar nochmal ein Update in Erwägung ziehen. Aber da gibt es ja sicher andere Prioritäten.

Aber ich habe eine Idee zu einem Tool, das den Interface-Quelltext analysiert, die fehlenden Getter und Setter (wie oben im Beispiel) ergänzt und dann die verwendenden Klassen zerlegt, ordnet, ergänzt, anhand der Interface-Vorgaben korrigiert und entsprechend dem obigen Beispiel neu zusammenbaut. So könnten viele, immer gleiche Arbeitsschritte deutlich reduziert werden.
(Angefangen habe ich damit schon.)

Meiner Meinung nach kann das extrem viel Arbeit ersparen und gleichzeitig die Übersichtlichkeit deutlich erhöhen.


Was meint Ihr dazu?
Habt Ihr Interesse an solch einem Tool?
Ist das überflüssig?

Gruß
Stahli


PS: Die externe Umsetzung halte ich für mich für machbar (so dass die Units einfach von der Exe geladen und aufbereitet werden). Damit das richtig komfortabel wäre müsste man das durch einen IDE-Experten realisieren, der auch scannen kann, welche Units unter "uses" stehen und diese nach der Interface-Deklaration durchsuchen. Dazu habe ich noch keine Vorstellung, wie das geht...

[Aviator]

Also ich arbeite in letzter Zeit fast ausschließlich mit Interfaces. Alle Punkte die du angesprochen hast, habe ich jetzt nicht direkt verstanden, bin aber auch nur relativ schnell über deinen Post hinweg geflogen.

Zu der Einsortierung in den Quelltext an einer bestimmten Position kann ich sagen, dass ich da früher darauf geachtet habe. Aber heute verwende ich ausschließlich die Methodenliste des CnPacks. Einfach STRG + D, den Anfang des Methodennamens eingeben und Enter. Da interessiert mich im Prinzip nicht mehr wo die Methode wirklich steht. Ich nutze eben sehr viele Tastenkombinationen die mir das Leben in der IDE deutlich vereinfachen und somit auch gewisse Dinge nicht benötigt werden.

Das automatische Anlegen des privaten Feldes und das Ausfüllen der Getter/Setter wäre sicherlich eine schöne Sache. Aber oft mache ich im Getter und Setter noch diverse Abfragen um unnötige Zuweisungen zu vermeiden. Von daher wäre das für mich nur bedingt hilfreich.

Die Properties in der Klasse brauchst du gar nicht mehr anzulegen. Es reicht, einfach nur die Getter und Setter zu erzeugen. Die Properties werden durch das Interface zur Verfügung gestellt. Setzt natürlich voraus, dass du ausschließlich mit Interfaces im Zusammenhang mit der Klasse arbeitest.

Das mal dazu wie ich damit umgehe. Manchmal würde ich mir allerdings wünschen, dass ein STRG + Klick bzw. ein STRG + G zum Springen zur Methode nicht zur Interface-Deklaration sondern zur Klasse die an dieser Stelle instanziiert wird zu springen. Visual Studio macht so etwas. Das schaut sich an, welche Klasse der Interface Variablen zugewiesen wurde und springt dann direkt zur Klasse und nicht zum Interface.

[jaenicke]

Ich kann dir nur Modelmaker Code Explorer empfehlen. Damit kann man viel zu den Punkten umsetzen, die du angesprochen hast.

Die Sortierung der Methoden geht damit zwar, aber da achte ich gar nicht drauf. Die ist mir ziemlich egal.

Zu Punkt 3... Dafür gibt es ja die Klassenvervollständigung. Die legt das automatisch an.

Und die Deklarationen aus einen Interface kann man auch automatisch übernehmen, auch ohne Addon.

[stahli]

Oh, man beachte die zwei letzten Beiträge:
http://www.delphipraxis.net/130219-i...eexplorer.html

Ich hatte MM und MMX völlig verdrängt.
Werde mir jetzt mal die Demos laden.

Scheint ja ganz gut auf meine Wünsche zu passen.
Gute, aktuelle Video-Tutorials (mit sprachlichen Erläuterungen) wären sicher trotzdem sinnvoll (und würden den Verkauf unterstützen) ...


@jaenicke
Trotzdem mal die Frage: Delphi legt Klassenvervollständigung und Methodenübernahme von Interfaces legt ja aber keine privaten Felder an - oder gibt es das doch irgendwie?

[himitsu]

Interfaces haben eigentlich keine Property, da gibt es nur Methoden, auch wenn Delphi hier die Property mit anbietet.
Aber daher fehlt dafür dann auch die automatische Codeverfolständigung.
Obwohl man sich natürlich fragen könnte, warum für Interfaces nicht einfach die Vervolständigung für Klassen verwendet wird/kopiert wurde. (abzüglich der Methodenimplementation und der Felder)

Private: Private Felder werden angelegt, für Property.
Außer in der Starter, da fehlt eh Vieles.

Delphi-Quellcode:

type
  TMyClass = class
    property Name1: string read GetName1 write SetName1;  // Template prop
    property Name2: string read FName2   write FName2;    // Template propf
    property Name3: string read GetName3 write SetName3;  // Template propgs
    property Name4: string read GetName4;  // Template propro
    property Name5: string read FName5;    // Template proprof
    property Name6: string write FName6;
  end;

  TMyClass = class
  private
    FName2: string;
    FName6: string;
    FName5: string;
    function GetName1: string;
    function GetName3: string;
    function GetName4: string;
    procedure SetName1(const Value: string);
    procedure SetName3(const Value: string);
  published
    property Name1: string read GetName1 write SetName1;  // Template prop
    property Name2: string read FName2   write FName2;    // Template propf
    property Name3: string read GetName3 write SetName3;  // Template propgs
    property Name4: string read GetName4;  // Template propro
    property Name5: string read FName5;    // Template proprof
    property Name6: string write FName6;  // !!! hier legt Delphi mir manchmal auch noch den Getter an, egal ob ich will oder nicht !!!
  end;

Interface-Methoden legt nicht ver Klassenvervollständigung (Strg+Shift+C) an, sondern das übernimmt "teilweise" die Code-Vervolständigung (Strg+Leertaste),
aber du mußt da selber auswählen was du willst. Wenigstens mit Multiselect, auch wenn es schwachsinn ist, denn von Interfaces müssen sowieso immer alle Methoden implementiert werden, dann könnte Delphi da auch von Selber gleich alles anlegen.

Die Codevervollständigung legt "eigentlich" alles alphaetisch an.
Und ja, mir wäre die Reihenfolge der Implementation auch lieber.
Und obwohl das alphabetisch rein kommt, dreht es schnell durch, wenn einmal in der Implementation die Reihenfolge der vorher bestehenden Methoden nicht stimmt, oder wenn man überladene Methoden hat, dann wird schnell mal was zu früh eingefügt.

[stahli]

@himitsu

Das Interface erzwingt ja Getter und/oder Setter, also akzeptiert kein privates Feld.
Daher wäre wünschenswert (gewesen), dass in Deinen Beispielen von der Codevervollständigung ein privates Feld fName1 angelegt und in Getter und Setter gelesen bzw. zugewiesen wird.


@all

Der ModelMaker Code Explorer scheint wirklich schon sehr gut das zu sein, was ich mir wünschen würde.
Da stellt sich die Frage: Lohnt es sich vielleicht direkt, gleich Nägel mit Köpfen zu machen und auch den ModelMaker zu nutzen?
Wenn der MM genutzt wird, bringt dann der MMX noch etwas?

Ich kann die Zusammenhänge immer noch nicht so genau einordnen.

[stahli]

Hier nochmal ein neuer Zwischenstand.

Im ersten Text ist verkürzt eine Klasse deklariert und nach Tastendruck wird daraus das nachfolgende Ergebnis generiert.
Es geht noch nicht alles, aber die Idee dahinter sollte schon mal gut erkennbar sein.

Es werden die Methoden, Properties und privaten Felder erzeugt und auch die Methoden soweit möglich vorausgefüllt. Das natürlich nur, wenn sie neu generiert werden. Spätere händische Änderungen bleiben natürlich bei künftigen Optimierungen erhalten.

Der Implementationsteil wird analog dem Interfaceteil sortiert. Das gilt auch, wenn die Reihenfolge der Klassen oder Klassenmember im Interfaceteil nachträglich verändert wird. Bei der nächsten Optimierung werden dann die Klassen und Methoden im Implementationsteil an die neue Reihenfolge im Interfaceteil angepasst.

Derzeit habe ich die Getter und Setter mit _get_... und _set_ benannt und die privaten Felder mit "f".
Außerdem habe ich in generierten Methoden ein ? eingesetzt, damit man die Methoden mindestens einmal bearbeitet.
In Settern prüfe ich erst auf eine Werteänderung.
Das alles lässt sich natürlich ggf. auch über Optionen steuern, falls daran Bedarf wäre.


Original:

Delphi-Quellcode:

unit Unit2;

interface

uses
  System.Classes, Vcl.Graphics, System.Types, System.UITypes;

const

  aConst = 100;

type

  TClass1 = class
  private
    procedure PrivProc; virtual;  
  public
    constructor Create; virtual;
    destructor Destroy; override;
  public
    procedure Execute(NewVal: String); virtual;
    function TestFunc(var Val1: Integer): Boolean;
    prop PropString: string;
    prop PropInteger: Integer rf;
    prop PropBoolean: Boolean v ws vi;
    prop PropByte: Byte s;
    prop PropWord: Word c w rf;
    prop PropString2: string c vi;
  end;

implementation

end.

Ergebnis:

Delphi-Quellcode:

unit Unit2;

interface

uses
  System.Classes, Vcl.Graphics, System.Types, System.UITypes;

const

  aConst = 100;

type

  TClass1 = class
  private
    fPropString: string;
    fPropInteger: Integer;
    fPropBoolean: Boolean;
    fPropByte: Byte;
    fPropWord: Word;
    fPropString2: string;
    procedure PrivProc; virtual;
    function _get_PropString: string;
    procedure _set_PropString(aValue: string);
    procedure _set_PropBoolean(var aValue: Boolean); virtual;
    function _get_PropByte: Byte; stdcall;
    procedure _set_PropByte(aValue: Byte); stdcall;
    function _get_PropString2: string; virtual;
    procedure _set_PropString2(const aValue: string); virtual;
  public
    constructor Create; virtual;
    destructor Destroy; override;
    procedure Execute(NewVal: String); virtual;
    function TestFunc(var Val1: Integer) Boolean
    property PropString: string read _get_PropString write _set_PropString;
    property PropInteger: Integer read fPropInteger;
    property PropBoolean: Boolean write _set_PropBoolean;
    property PropByte: Byte read _get_PropByte write _set_PropByte;
    property PropWord: Word read fPropWord;
    property PropString2: string read _get_PropString2 write _set_PropString2;
  end;

implementation

{ TClass1 }

constructor TClass1.Create;
begin

end;

destructor TClass1.Destroy;
begin

end

procedure TClass1.PrivProc;
begin
  ?;
end

function TClass1._get_PropString: string;
begin
  Result := fPropString;
end

procedure TClass1._set_PropString(aValue: string);
begin
  if (fPropString <> aValue) then
  begin
    fPropString := aValue;
  end;
end

procedure TClass1._set_PropBoolean(var aValue: Boolean);
begin
  if (fPropBoolean <> aValue) then
  begin
    fPropBoolean := aValue;
  end;
end

function TClass1._get_PropByte: Byte;
begin
  Result := fPropByte;
end

procedure TClass1._set_PropByte(aValue: Byte);
begin
  if (fPropByte <> aValue) then
  begin
    fPropByte := aValue;
  end;
end

function TClass1._get_PropString2: string;
begin
  Result := fPropString2;
end

procedure TClass1._set_PropString2(const aValue: string);
begin
  if (fPropString2 <> aValue) then
  begin
    fPropString2 := aValue;
  end;
end

procedure TClass1.Execute(NewVal: String);
begin
  ?;
end

function TClass1.TestFunc(var Val1: Integer): Boolean;
begin
  Result := ?;
end

end.

Als nächstes will ich jetzt die Optimierung von Interfaces und von Klassen, die Interfaces verwenden, umsetzen.
Dann würden entsprechende Deklarationen wie oben im Interface automatisch auf die das Interface verwendenden Klassen durchschlagen.
In der Klasse gäbe es dann Sektionen wie

Delphi-Quellcode:

private // Intf1
  fProp: Integer
protected // Intf1
  function _get_Prop: Integer;
public // Intf1
  property Prop: Integer read _get_Prop;

Spätere Änderungen im Interface würden automatisch auf die Klassen durchschlagen. Das wird (mit einer entsprechenden Anweisung) sogar für Umbenennungen von Properties und Methoden möglich sein, so dass eine InterfaceMember-Namensänderung nacheinander in mehreren Projekten nacheinander automatisiert durchgeführt werden kann (allerdings dann wohl nur bei den Klassenmembern, nicht als wirkliches Refactoring).


Wird das jetzt interessanter?

[freimatz]

Für mich Nein, sorry. Ich nehm meist den MMX für so was.
Übrigens habe ich mir auch ein Tool für DTO-Datenklassen gemacht. Man schreibt ein interface (mit oder ohne Getter) und das Tool ergänzt die interfaces, erstellt die Klassen die das implementieren und dazu noch Fabrikmethoden und auf Wunsch records dazu.

[jaenicke]

Zitat von stahli:

Derzeit habe ich die Getter und Setter mit _get_... und _set_ benannt und die privaten Felder mit "f".

Schöner wäre, sich an den Styleguide (und die interne Implementierung der Klassenvervollständigung von Delphi) zu halten...
Dass da immer wieder jemand sein eigenes Süppchen kocht, ist echt suboptimal.

Da das ein Tool vor allem für dich selbst ist, bist du da natürlich frei, aber so wird es dann wohl auch eher eine Lösung bleiben, die sonst nicht viele nutzen möchten. Gerade die Verwendung von Standards ist in vielen Bereichen wirklich hilfreich (und trägt zur Verbreitung einer Lösung bei)...

Was ich tatsächlich nützlich finden würde, wäre, wenn man die Property normal hinschreiben könnte ohne read und write und dann analog zur Klassenvervollständigung Getter und Setter ergänzt würden.
Wie ich das aktuell mache, hatte ich ja schon geschrieben:
http://www.delphipraxis.net/1380202-post13.html
Das geht zwar sehr schnell, auch bei mehreren Properties, aber wenn das in einem Schritt ginge, wäre das schon schön.

Mit deiner Kurzschreibweise kann ich mich leider gar nicht anfreunden. Die paar Millisekunden Zeitersparnis beim Tippen (prop vs. property) sind für mich nicht relevant, da schreibe ich es lieber richtig...
Wenn statt prop PropString: string; das ganze auch mit property PropString: string; gehen würde, wäre das schon gut. Dann könnte es eine Alternative zur Klassenvervollständigung werden.

Trotzdem geht mit MMX aktuell noch deutlich mehr.

[stahli]

@freimatz

Ich hatte auch mal einen Codegenerator, der mir anhand von Datenstrukturen komplette Klassen erstellt hat. Das ist aber nicht vergleichbar mit der Änderung einer bestehenden Unit.

Kann Dein Tool so etwas auch? Ich würde es dann gerne übernehmen, wobei ich mit meinem jetzt auch schon recht weit und zufrieden bin.


@jaenicke

_get_ und _set_ verwende ich gern, weil Getter und Setter ja eher Hilfskonstrukte sind, die normalerweise nicht extern aufgerufen werden. So sind "echte Funktionen" wie GetBestFriends(1000) durch die Namensgebung besser von Gettern und Settern zu unterscheiden.
Aber wie gesagt, das ließe sich ja völlig unproblematisch über Optionen steuern.

Auch "property" auf Wunsch auszuschreiben wäre kein Problem. Die Codevervollständigung würde dann analog "prop" zuschlagen, wenn darauf kein read und kein write folgt (sonst wäre das Property ja schon mit einem read und/oder write vollständig deklariert und dürfte nicht mehr automatisch verändert werden).

Klar ist der MMX komplexer, mir aber zu umständlich. Mein Tool sehe ich einfach als Codevervollständigung 2.0 + UnitSortierer.
Meiner Arbeitsweise kommt das (wenn es fertig wird, wie erhofft) sehr viel mehr entgegen.

Wenn man in Interfaces oder im Interfaceteil von Klassen bestimmte Vorgaben trifft, ergibt sich daraus bereits exakt, was an anderen Stellen nochmal exakt so geschrieben werden muss. Und genau das nervt mich inzwischen extrem.