Interface-Unterstützung

[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

[stahli]

@Fritzew

Auf die Properties in den Klassen zu verzichten ist eine Überlegung wert.
Andererseits hat man mit den Properties auch einen kompletten Überblick über die Klassenmember innerhalb der Klassenmethoden.

Die Klassenunits verstecke ich mittlerweile regelmäßig hinter einer Factory, so dass ich auf der Projektlogik heraus ohnehin nur noch die Interfaces sehe.

Also ich werde die Properties weiter in den Klassen aufnehmen, könnte das aber optional auch ausschalten lassen.

Ist wohl eher Geschmacksache.


@Mavarik

Das Schieben von Gettern und Settern in Interfaces nach ganz oben finde ich gut. Werde ich so umsetzen.
(Im Grunde sollten die gar nicht geschrieben werden müssen und im Interface stehen. Ist ja ohnehin klar, wie die aussehen müssen.)

Die Properties selbst würde ich (wie oben beschrieben) eher mit in die Klassen übernehmen - optional abschaltbar.

Deine Einrückungen finde ich gewöhnungsbedürftig und bin noch unschlüssig, ob ich das gut finde oder nicht so gut.
Mich würde es stören, auf den Codeformatierer (von Delphi oder Third Party) verzichten zu müssen und das alles von Hand zurecht zu schieben. Wenn Du ein Property kürzer oder länger umbenennst wird das ja eine Schiebe-Orgie.

Aber ich kann mal schauen, ob ich eine solche Funktion mit unterbringen kann. Das Tool müsste halt hinter "function"-Deklarationen zwei Leerzeichen einfügen und bei gleichenartigen Zeilen untereinander bestimmte "virtuelle Tabs" benutzen.

Auch hatte ich schon mal überlegt, Code mit diesen Verkettungen (ich weiß gerade nicht wie man das nennt)

Code:

X := Y(123).
{}   Z(234);

automatisch auszurichten, was Du immer mit den geschweiften Klammern machst.

Das würde mich ja rammdösig machen...

[Mavarik]

Zitat von stahli:

Mich würde es stören, auf den Codeformatierer (von Delphi oder Third Party) verzichten zu müssen und das alles von Hand zurecht zu schieben.

100% richtig... Ich habe auch noch auf meiner ToDo Liste stehen einen eigenen Formatter zu programmieren...

Hab für die Unicode umstellen schon die ein oder anderen Sourcecode Analyse geschrieben... Aber bisher fehlte mir einfach die Zeit.

[stahli]

Hier mal ein aktueller Zwischenstand als Video: https://youtu.be/cfKa3wuoEd0

Der Optimizer funktioniert schon mal als erster Test innerhalb der IDE.
Eine direkte Codeformatierung (Einrückung) habe ich noch nicht drin, will das aber auch noch ergänzen.
Die anderen Features gehen für mich aber vor.

Findet das JETZT vielleicht jemand interessant?

Ich würde das später sehr gern kommerziell anbieten, wenn es Nachfrage gibt.
Für öffentliche Tests ist es noch etwas früh. Dazu muss ich noch einiges ausbauen und ausbessern.
Sofern jemand Erfahrungen mit den OTA hat und daran mitarbeiten möchte, dann gebt Bescheid...

[stahli]

Weiter hier: https://www.delphipraxis.net/196493-...ml#post1402947