Interface-Unterstützung

[stahli]

Alle Sonderfälle kann man sicher nicht abdecken, aber jetzt kann man ein altes Property einfach durch ein neues überschreiben...

alt:

Delphi-Quellcode:

  iMyBaseIntf = Interface // mehrfache Methoden hier nur zum Test
    function _get_BaseProp: string;
    procedure _set_BaseProp(aTestS: string);
    prop BaseProp:integer; // überschreibt evtl. vorhandene Property sowie Getter und Setter
    function _get_BaseProp: Boolean;
    procedure _set_BaseProp(aTestB: Boolean);
    property BaseProp: Boolean read _get_BaseProp write _set_BaseProp;
  end;

neu:

Delphi-Quellcode:

  iMyBaseIntf = Interface
        function _get_BaseProp: integer;
        procedure _set_BaseProp(aValue: integer);
        property BaseProp: integer read _get_BaseProp write _set_BaseProp;
  end;

Der nächste Schritt soll sein, dass man einfach BaseProp: integer in BaseProp: Boolean ändern kann und dadurch Getter und Setter im Interface angepasst werden.

Die Klassen werden dann unabhängig von der Ausgangssituation an die aktuelle Interface-Deklaration angepasst.

[stahli]

Anbei mal eine erste Testversion, die schon mal zwei Units (_unit1 und _unit2) ordnet und sortiert.
In den zwei Memos links sind die Originale und rechts die Ergebnisse dargestellt.

Die beigefügten Units sind verstümmelte Units von mir.
Unit1 enthält einige Klassen und Unit2 für später die zugehörigen Interfaces (diese könnten aber dann auch direkt in der Unit1 deklariert sein).
Die Interfaces werden aktuell allerdings noch nicht berücksichtigt.

Die Unit1 wird aktuell vernünftig umsortiert.

Einige Dinge funktionieren noch nicht. Direkt fallen mir ein:
- class Variablen, Funktionen etc
- Embedded functions/procedures
- strict private etc
- overloads
- Klassen- und Interfacedeklarationen im Implementationsteil

Eine besondere Schwierigkeit beim Umsortieren sind Zeilenumbrüche und Kommentare mitten im Code.
Es kann schon sein, dass Eure Code-Styles aktuell nicht korrekt unterstützt werden.


Als nächstes will ich erst mal die oben schon erläuterte "prop"-Interpretation umsetzen. Für die Interfaces hatte ich das ja schon mal realisiert, muss das aber nochmal auf den neuen Parser anpassen.
Dann können z.B. durch
"prop MyProp:Integer rf wf;" ein Property mit privatem Feld und durch
"prop MyProp:Integer;" ein Property mit Getter und Setter (+privatem Feld) erzeugt werden.
Wenn der Property-Typ geändert wird, wird schlägt das automatisch auf die Getter, Setter und privaten Felder durch.

Außerdem sollen neue Deklarationen von Methoden im Implementationsteil entsprechende neuen Methoden erzeugen.
Änderungen von Parametern sollen in den Implementationsteil übernommen werden. Umbenennungen von Parametern könnte das Tool erkennen und im Methodenbody nachführen (das wäre das einzige wirkliche "Refactoring" durch das Tool).


Zum Schluss sollen dann alle Deklarationen in Interfaces automatisch in den Klassen realisert/angepasst werden, die dieses Interface verwenden.
Wenn z.B. eine Klasse nicht kompiliert und man das Tool startet, würden die notwendigen Deklarationen aus dem Interface in einer Standardform implementiert und können bei Bedarf noch überarbeitet werden.


Im Grunde wäre das Tool eine neue Klassenvervollständigung + Interface-Berücksichtigung + Unit-Neuordnung.


Die Frage ist, wie weit man das treiben will und soll.
Man könnte auch einen kompletten Code-Formatierer daraus bauen (wobei mir eigentlich der eingebaute reicht).
Vielleicht mit Ausrichtung der Punkte bei FluentInterfaces?

Habt Ihr dazu Bedarf/Meinungen?


In jedem Fall will ich das Tool später mal in die IDE integrieren.
Dazu wäre es cool, wenn ich die Interfaces-Units aus der Klassendeklaration finden könnte (also die Unit, die durch Ctrl+Click auf IMyIntf geöffnet wird).
Noch braucht es etwas Zeit bis dahin. Aber kennt sich damit jemand aus?

[stahli]

Gibt´s da wirklich kein Interesse?

Wenn ich das so realisieren kann würde das m.E. eine große Schwäche der Delphi-IDE ausbessern und auch effektiver sein als der ModelMaker Code Explorer.

[TiGü]

Was mir bei deinen Überlegungen fehlt, ist folgender Sachverhalt:
Die Klassen, die das zu refaktorierende Interface implementieren, müssen nicht zwangsläufig im gerade aktuell geladenen Projekt zu finden sein.
Ggf. sind die in einen anderen Projekt zu finden, welches auch dieses Interface verwendet. Oder sind in einer BPL oder DLL.
Oder sind gar keine Delphi-Klassen, sondern in irgendeiner anderen Sprache in einen anderen Modul implementiert.

Falls man wirklich mehr als drei Zeilen am Interface ändert, dann macht man Copy&Paste und tackert das in die Klasse rein und passt entsprechend an.
Vielleicht ist mein Leidensdruck auch nicht so hoch, weil sich relativ schnell eine fertige Property- und Methodendefinition feststeht.

[stahli]

Klassen in anderen Projekten werden natürlich nicht berücksichtigt.

Der Ablauf wäre folgender:

1) Interface überarbeiten
z.B. "prop MyIntf: Integer"
wodurch gleich auch Getter und Setter im Interface ergänzt werden.

2) Projekt kompilieren, und die Units, die nicht kompiliert werden können nacheinander durch das Tool optimieren lassen (z.B. Ctrl+Shift+O, wenn es als IDE-Experte implementiert ist).
Dadurch werden in den Klassen die Property, Getter und Setter ergänzt. Darüber hinaus auch ein passendes privates Feld und Standardcode im Getter und Setter.

3) Die Methoden im Implementationsteil werden analog zur Reihenfolge in den Klassendeklarationen sortiert.


Mein Leidensdruck ist dabei extrem hoch, da bei jedem neuen Property in den Interfaces dieser ganze Mist immer wieder genau gleich in allen benutzenden Klassen durchgeführt werden muss.

[TiGü]

Zitat von stahli:

Mein Leidensdruck ist dabei extrem hoch, da bei jedem neuen Property in den Interfaces dieser ganze Mist immer wieder genau gleich in allen benutzenden Klassen durchgeführt werden muss.

Kannst du dazu ein Beispiel aus der Praxis liefern?
Wenn ich bspw. ein Interface habe und drei verschiedene Klassen, die dieses Property implementieren müssen und das ggf. sogar auf gleicher Art und Weise, dann mach ich mir doch eine Basisklasse dazu und frühstücke das da ab.
Oder wenn sich das nur in einer von drei Klassen verschieden verhalten sollte, dann mach ich das auch in die Basisklasse und und mache Setter und Getter virtual und überschreibe in den richtigen Klassen entsprechend.

[stahli]

Ich arbeite quasi nur noch mit Interfaces und meine Klassen implementieren jeweils sehr unterschiedliche (je nach erforderten Funktionalitäten).
Eine Interfaceänderung wirkt sich somit auf viele unterschiedliche Klassen aus.

Der maßgebliche Grund für meinen Leidensdruck ist allerdings, dass ich nicht verstehe, dass man als Hightec-Softwareschmiede über die Jahre so etwas nicht mal vernünftig unterstützt.

Wenn ich eine Kundenverwaltung schreibe, achte ich doch auch darauf, dass der Anwender die Kundendaten nicht 3 mal eingeben muss und das Programm Fehlermeldungen wirft, wenn die 3 Datenbestände nicht zusammenpassen.

Ok, die Pascal-Struktur neu zu entwickeln wäre überzogen und ist nicht notwendig, aber zumindest sollte die IDE einem die Redundanzen etwas abnehmen und die Units vernünftig sortieren.
Mich regt das wirklich auf und hier könnte doch eigentlich relativ leicht Abhilfe geschaffen werden.

Mir fällt das natürlich schwerer als einer Hightec-Softwareschmiede, aber ich versuche das mal...