Interface-Unterstützung

[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.

[freimatz]

Mein Tool ist nicht unviversell brauchbar. Erstmal ist er nur für Transferobjekte da. Weiter wird formatierter Code verlangt so wie es unser Formatter macht. Dann ist das Tool ein Gebastel und mit <duck>VS/C#</duck> erstellt. Neuerdings sollte das Tool auch mit bestehenden units klar kommen.
Zum Verständnis noch ein Beispiel:
Gegeben

Delphi-Quellcode:

  IBlafaselCalculatorSourceData = interface(IBlaCalculatorSourceData)
    ['{FDFBCC49-C16F-4BC1-B6BF-7926EA37113F}']
    property ToleranceZoneGeometry: IToleranceZoneGeometryBase;
    property PreparedPoints: TPreparedPoints;
  end;

Dann wird da draus:

Delphi-Quellcode:

  IBlafaselCalculatorSourceData = interface(IBlaCalculatorSourceData)
    ['{FDFBCC49-C16F-4BC1-B6BF-7926EA37113F}']
    function GetToleranceZoneGeometry(): IToleranceZoneGeometryBase;
    function GetPreparedPoints(): TPreparedPoints;

    property ToleranceZoneGeometry: IToleranceZoneGeometryBase read GetToleranceZoneGeometry;
    property PreparedPoints: TPreparedPoints read GetPreparedPoints;
  end;
...
function CreateBlafaselCalculatorSourceData(
  ... Zeug von Vorfahre
  const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
  const p_PreparedPoints       : TPreparedPoints): IBlafaselCalculatorSourceData;
...
  TBlafaselCalculatorSourceData = class(TBlaCalculatorSourceData,
    IBlafaselCalculatorSourceData)
  strict private
    FToleranceZoneGeometry: IToleranceZoneGeometryBase;
    FPreparedPoints       : TPreparedPoints;
    function GetToleranceZoneGeometry(): IToleranceZoneGeometryBase;
    function GetPreparedPoints(): TPreparedPoints;

  public
    constructor Create(
      ... Zeug von Vorfahre
      const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
      const p_PreparedPoints       : TPreparedPoints);
    property ToleranceZoneGeometry: IToleranceZoneGeometryBase read GetToleranceZoneGeometry;
    property PreparedPoints: TPreparedPoints read GetPreparedPoints;
  end;
...
constructor TBlafaselCalculatorSourceData.Create(
  ... Zeug von Vorfahre
  const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
  const p_PreparedPoints       : TPreparedPoints);
begin
  inherited Create(... Zeug von Vorfahre);
  FToleranceZoneGeometry := p_ToleranceZoneGeometry;
  FPreparedPoints := p_PreparedPoints;
end;
...
constructor TBlafaselCalculatorSourceData.Create(
  ... Zeug von Vorfahre
  const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
  const p_PreparedPoints       : TPreparedPoints);
begin
  inherited Create(... Zeug von Vorfahre);
  FToleranceZoneGeometry := p_ToleranceZoneGeometry;
  FPreparedPoints := p_PreparedPoints;
end;
...
constructor TBlafaselCalculatorSourceData.Create(
  ... Zeug von Vorfahre
  const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
  const p_PreparedPoints       : TPreparedPoints);
begin
  inherited Create(... Zeug von Vorfahre);
  FToleranceZoneGeometry := p_ToleranceZoneGeometry;
  FPreparedPoints := p_PreparedPoints;
end;

function TBlafaselCalculatorSourceData.GetToleranceZoneGeometry(): IToleranceZoneGeometryBase;
begin
  Result := FToleranceZoneGeometry;
end;

function TBlafaselCalculatorSourceData.GetPreparedPoints(): TPreparedPoints;
begin
  Result := FPreparedPoints;
end;
...
function CreateBlafaselCalculatorSourceData(
  ... Zeug von Vorfahre
  const p_ToleranceZoneGeometry: IToleranceZoneGeometryBase;
  const p_PreparedPoints       : TPreparedPoints): IBlafaselCalculatorSourceData;
begin
  Result := TBlafaselCalculatorSourceData.Create(... Zeug von Vorfahre, p_ToleranceZoneGeometry, p_PreparedPoints);
end;

Der Record ist hier noch nicht dabei. Auch etliche REGIONS habe ich weggelassen.

[stahli]

Ich habe jetzt noch einen neuen Ansatz realisiert.
Das Tool analysiert die zusammenhängenden Blöcke und kennzeichnet sie farblich. (Umgebaut wird die Unit noch nicht.)

Es ist doch überraschend, wie unstrukturiert die Pascal-Unit wirklich ist. Es ist gar nicht immer so eindeutig zu erkennen, wo eine Anweisung zu Ende ist.

Das Tool ist ja kein Compiler und soll gar nicht wissen, was jedes Wort bedeutet. Es muss sich daher allein an der Struktur des Textes orientieren.

"virtual;" hinter einer Prozedur-Deklaration gehört noch zu ihr.
"end;" aber nicht.
"Quatsch ;" würde mit zur Prozedur gehören (auch wenn es natürlich kein Pascal-Schlüsselwort ist, könnte aber vielleicht ja in 2 Jahren eins werden )
"Quatsch!" würde wohl irgendwie zur Klassendeklaration gehören.

Zusätzlich können überall Leerzeichen, Kommentare und Zeichenumbrüche dazwischen stehen. Manche Anweisungen müssen mit ";" abgeschlossen werden, andere nicht, weitere werden trotz ";" fortgesetzt (wie bei "virtual")


Ich bin auf einem guten Weg, denke ich, aber es war kein leichter.



PS: Kennt jemand sich mit den Tool-Api´s aus im Sinne Refactoring und Code-Formatierung?

[freimatz]

Zitat von stahli:

Das Tool ist ja kein Compiler und soll gar nicht wissen, was jedes Wort bedeutet. Es muss sich daher allein an der Struktur des Textes orientieren.
...
Ich bin auf einem guten Weg, denke ich, aber es war kein leichter.

Auch wenn Du das nicht hören willst: Nein, du bist auf keinem guten Weg.
Ja, du machst keinen Compiler. Aber die Analyse sollte auf dem gleichen Weg passieren, also mit einem Parser. Sonst wird der Weg nie zu Ende sein. Ständig kommt dann irgendwelcher "Quatsch" daher an den du nicht gedacht hast. Pascal ist schließlich auch eine formatfreie Sprache.
Es gibt Parser. Hier in meiner Firma wird ein solcher auch verwendet um aus interfaces Mock-Objekte zu erzeugen. Auskennen tue ich mich da aber nicht, habe nur einmal was daran geändert.

[jaenicke]

Zitat von stahli:

Es ist doch überraschend, wie unstrukturiert die Pascal-Unit wirklich ist. Es ist gar nicht immer so eindeutig zu erkennen, wo eine Anweisung zu Ende ist.

Wenn man (wie ich bei meinen Experimenten ein Refactoring Tool zu bauen) einen Parser wie den von Castalia nimmt, ist das kein Problem.
Denn strukturiert ist das ganze schon eindeutig, nur wenn du mal z.B. in den genannten Parser hineinschaust, siehst du auch wie viele Fälle da eigentlich behandelt werden müssen...

[stahli]

Hi,

auch wenn mein Ansatz nicht so auf allgemeine Begeisterung stößt will ich mal etwas grundsätzliches fragen:

Welche Ordnung würdet Ihr innerhalb einer Interface- und Klassendeklaration bevorzugen?
Mein Tool soll ja einiges automatisieren. Jetzt stellt sich die Frage, wie es da heran gehen sollte.
Unabhängig davon, dass man natürlich (falls es doch mal Interesse gibt) auch Optionen anbieten sollte, möchte ich mal Eure Meinungen dazu anfragen.

Im Interface werden bei Properties die Getter und Setter ergänzt.
Ich würde diese jeweils unmittelbar vor den Properties einfügen in der Reihenfolge
Getter (wenn nötig), Setter (wenn nötig), Property.
Macht Ihr das anders?
Sollte vor dem Block noch eine Leerzeile zur besseren Übersichtlichkeit eingefügt werden?

Bei den Klassen habe ich verschiedene Ideen.

Class1:
Man könnte alles (klasseneigene und Interface-Member) zusammen in die normalen Sektionen (private, protected und public) schreiben.

Class2:
Oder man erzeugt eigene Sektionen (private, protected und public) pro Interface und beschriftet diese (mit einem Kommentar).

Class3:
Wie Class2 aber die Interface-Sektionen kommen alle zum Schluss.

Class4:
Alle Interface-Member kommen einfach in eine beschriftete public-Sektion.

Im letzten Beispiel habe ich ich auch mal eine eigene Sektion vorgesehen, in die alle Getter und Setter kommen könnten (entweder nur die von der Klasse selbst oder auch alle Getter und Setter, die zu den Interfaces gehören).


Zu entscheiden wäre auch, ob private Felder sowie Getter und Setter jetzt eher in protected oder private sections gehören.
Das Tool soll bestehende Ordnungen NICHT durcheinander bringen aber ich müsste entscheiden, wie es mit automatischen Ergänzungen umgehen soll.
Was sind da Eure Ideen und Meinungen?

Delphi-Quellcode:

interface

IIntf1 = interface 
  procedure Proc(Param: String);
  function Func(var Param: Integer): Boolean; 

  function Getter1: string; 
  procedure Setter1(aValue: string); 
  property Prop1: string read Getter1 write Setter1;

  function Getter2: string; 
  procedure Setter2(aValue: string); 
  property Prop2: string read Getter2 write Setter2;
end; 

TClass1 = class(TInterfacedObject, IIntf1) 
private 
  fNew: String;
  fProp1: string; 
  fProp2: string; 
protected
  function GetterNew: string; 
  procedure SetterNew(aValue: string); 
  function Getter1: string; 
  procedure Setter1(aValue: string); 
  function Getter2: string; 
  procedure Setter2(aValue: string); 
public 
  constructor Create; virtual; 
  destructor Destroy; override; 
  procedure New;
  procedure Proc(Param: String);
  function Func(var Param: Integer): Boolean; 
  property New: string read GetterNew write SetterNew;
  property Prop1: string read Getter1 write Setter1;
  property Prop2: string read Getter2 write Setter2;
end; 

TClass2 = class(TInterfacedObject, IIntf1) 
private 
  fNew: String;
private // IIntf1
  fProp1: string;
  fProp2: string; 
protected
  function GetterNew: string; 
  procedure SetterNew(aValue: string); 
protected // IIntf1
  function Getter1: string; 
  procedure Setter1(aValue: string); 
  function Getter2: string; 
  procedure Setter2(aValue: string); 
public 
  constructor Create; virtual; 
  destructor Destroy; override; 
  procedure New;
  property New: string read GetterNew write SetterNew;
public // IIntf1
  procedure Proc(Param: String);
  function Func(var Param: Integer): Boolean; 
  property Prop1: string read Getter1 write Setter1;
  property Prop2: string read Getter2 write Setter2;
end; 

TClass3 = class(TInterfacedObject, IIntf1) 
private 
  fNew: String;
protected
  function GetterNew: string; 
  procedure SetterNew(aValue: string); 
public 
  constructor Create; virtual; 
  destructor Destroy; override; 
  procedure New;
  property New: string read GetterNew write SetterNew;
private // IIntf1
  fProp1: string; 
  fProp2: string; 
protected // IIntf1
  function Getter1: string; 
  procedure Setter1(aValue: string); 
  function Getter2: string; 
  procedure Setter2(aValue: string); 
public // IIntf1
  procedure Proc(Param: String);
  function Func(var Param: Integer): Boolean; 
  property Prop1: string read Getter1 write Setter1;
  property Prop2: string read Getter2 write Setter2;
end; 

TClass4 = class(TInterfacedObject, IIntf1) 
private 
  fNew: String;
protected // Getter&Setter
  function GetterNew: string; 
  procedure SetterNew(aValue: string); 
public 
  constructor Create; virtual; 
  destructor Destroy; override; 
  procedure New;
  property New: string read GetterNew write SetterNew;
public // IIntf1
  fProp1: string; 
  fProp2: string; 
  function Getter1: string; 
  procedure Setter1(aValue: string); 
  function Getter2: string; 
  procedure Setter2(aValue: string); 
  procedure Proc(Param: String);
  function Func(var Param: Integer): Boolean; 
  property Prop1: string read Getter1 write Setter1;
  property Prop2: string read Getter2 write Setter2;
end; 

implementation 

...

end.

[Fritzew]

Also ich würde sagen alle Interface Methoden privat oder protected für Ableitungen (wenn notwendig).
Keine davon public in den implementierenden Klassen.
Die properties selber nicht in die Klassen, nur Setter und Getter.
Dadurch verhindert man das mixen von Class und Interface. Zugriff nur über das Interface.
Aber das ist natürlich nur meine Meinung, bewährt sich hier aber.

[Mavarik]

Zitat von stahli:

auch wenn mein Ansatz nicht so auf allgemeine Begeisterung stößt will ich mal etwas grundsätzliches fragen:

also....

Für das erzeugen des Interfaces habe ich ein Livetemplate...

ipropgs ipropg

Die Erzeugen mir ein Interface mit den propertys mit oder ohne setter.

Schön wäre es wenn eine automatische Sortierung passieren würde.

die propertys werden in der classe logischerweise nicht gebraucht.

Zu meinen Besonderheiten:
Source in der Anlage als Bild (Beispiel) da hier der Delphi-Formatter der DP - wahrscheinlich aus gutem Grund - MEINE Formatierung zerstört.

1.) In Propertys stehen die read und writes untereinander!
2.) Funktionen haben immer ein doppeltest Space, damit die Namen untereinander stehen.
3.) Setter haben immer den Parameter "AValue"
4.) In der Classe gibt es pro Interface ein "strict private" um zu signalisieren, dass diese Methoden aus dem Interface kommen. Wenn es mehr als ein Interface gibt steht hinter "strict private // IFoo" der Interfacename
5.) Die Variabel kommen jeweils unter eine eigen private Unterteilung - Natürlich mit großem "F" und Doppelpunkte untereinander.
6.) Immer ein AfterConstruction / BeforeDestruction da ich i.d.R. die Instance über eine Factory erzeuge und daher keine Create procedure verwende um parameter zu übergeben.

Ich habe noch viele Kleinigkeiten die mir das Sourcecode lesen erleichtern, aber das soll erstmal reichen.

Mavarik