Methoden-Deklaration vorgeben?

Das habe ich aber noch in keiner Sprache gesehen.

Natürlich nicht, weil man sich damit zum Horstl macht. Man verwendet eine Factory. Deshalb wurden die ja erfunden. Wenn ich in einer Klasse alle Handler/Methoden unterbringe, dann verstoße ich z.B. gegen das Open/Closed-Prinzip und meine Klasse degeneriert immer weiter, d.h. wird immer größer und größer => Ganz ganz schlecht und peinlich.

Also: Mach es wie Sir Rufo vorgeschlagen hat: Nimm eine Factory.

**BUG**

Zitat von Furtbichler:

Natürlich nicht, weil man sich damit zum Horstl macht. Man verwendet eine Factory. Deshalb wurden die ja erfunden.

Das Problem war imho nicht:
"Wie teile ich Methoden auf Klassen auf." => Factories, usw.
sondern:
"Wie vermeide ich es, tausendmal (auch in verschiedenen Klassen) die gleiche Signatur zu tippen.".

Gerade bei

SirRufus' Lösung muss man bei jeder Implementierung von IMyMethod bei jeder Deklaration und jeder Definition der Methode die gleiche Signatur tippen.
Oder übersehe ich da etwas?

BTW: Meine "Lieblingslösung" wurde ja schon im Ausgangspost genannt

Zitat von BUG:

Das Problem war imho nicht...

Dummdidumm: Wie man vom Thema abweichen kann.. Hast Recht.
Aber falsch ist die Vorgehensweise trotzdem. So.

Bei VS bzw. Resharper geht das ganz einfach:

markieren

Code:

class MyNewClass : IMyMethod{}

ALT-Enter, Enter, fertig (Refactoring "Implement Methods" wird ausgeführt). Gibts da was für Delphi?

Zitat von Der schöne Günther:

Nur meiner Meinung nach für so klitzekleine Dinge wie in meinem Beispiel trotzdem etwas ... oversized.

Falsche Meinung.

Gewöhne Dir das einfach an. Factories sind soooo praktisch und dir wird alle Nase lang etwas über den Weg laufen, wo Du anhand eines Tokens (String, Enum, sonstewas) eine Methode aufrufen musst.

**Der schöne Günther**

Zitat von Furtbichler:

Gibts da was für Delphi?

Interfaces in Delphi habe ich mir immer noch nicht angeschaut, aber ich meine Vorgaben vom zu implementierenden Interface auf Methoden von aggregierten Objekten delegieren.

Zitat von Furtbichler:

Falsche Meinung.

Gewöhne Dir das einfach an.

Ich versuchs. Später rächt sich das immer

**jaenicke**

Zitat von Furtbichler:

Bei VS bzw. Resharper geht das ganz einfach:

markieren

Code:

class MyNewClass : IMyMethod{}

ALT-Enter, Enter, fertig (Refactoring "Implement Methods" wird ausgeführt). Gibts da was für Delphi?

Nicht für Delphi, sondern direkt schon in Delphi drin:
Klassendeklaration hinschreiben inkl. end, vor dem end bleiben, Strg + Leertaste, zu implementierende Methoden des Interfaces aus der Liste auswählen, Enter (jetzt stehen sie da inkl. public), Strg + Shift + C, fertig.

**Sir Rufo**

@jaenicke

Obwohl mich das public eher stört, das verleitet einige statt dem Interface, die Klassen-Instanz zu benutzen.

Also definiere ich die Klassen entweder im implementation -Abschnitt (Zugriff dann über eine Factory) oder deklariere diese Methoden als protected .

**jaenicke**

Zitat von Sir Rufo:

Obwohl mich das public eher stört, das verleitet einige statt dem Interface, die Klassen-Instanz zu benutzen.

Wenn sie denn verfügbar wäre. Bei den Interfaces, die ich im Moment implementiere, ist in der Schnittstelle nach außen nur das Interface verfügbar.
Das Interface deklarierst du ja hoffentlich nicht in der selben Unit wie das Objekt, oder?
Wer dann die Unit mit dem Objekt extra nimmt, ist selbst schuld...

Nebenbei kann man bei XE4 anders als früher auch problemlos den Interface-Zeiger wieder auf die Objektinstanz casten (mit as).

Auch noch nebenbei: Das Überschreiben von Elternmethoden funktioniert analog inkl. override dahinter.

Das public wieder zu entfernen ist jedenfalls deutlich weniger Arbeit als alles manuell zu kopieren usw.

Zitat von jaenicke:

Nicht für Delphi, sondern direkt schon in Delphi drin:...

Na dann hätten wir ja das Problem

Zitat von NamenLozer:

...Ändert allerdings auch nichts daran, dass man die Parameterdeklaration bei jeder Methode wieder hinschreiben muss.

gelöst hätten.

Interface-Methoden sollten public sein, schließlich verwendet man sie ja 'öffentlich', auch wenn die Klasse an sich nicht verfügbar sein sollte.

**jaenicke**

Zitat von Furtbichler:

Interface-Methoden sollten public sein, schließlich verwendet man sie ja 'öffentlich', auch wenn die Klasse an sich nicht verfügbar sein sollte.

Ich schreibe die immer unter protected um zu verhindern, dass man aus Versehen die Klasse als Klasse nutzt, wenn man diese noch nicht kennt.

**Namenloser**

@Sir Rufo, Furtbichler: Ändert allerdings auch nichts daran, dass man die Parameterdeklaration bei jeder Methode wieder hinschreiben muss.

Wenn dann würde sich vielleicht eher dieses Pattern anbieten, wo man statt die Parameter einzeln zu übergeben, ein einziges Objekt übergibt, das alle Parameter beinhaltet... mit Namen hab ichs nicht so

. So spielt die dann Reihenfolge keine Rolle und man kann auch neue Parameter hinzufügen, ohne alle Methoden anpassen zu müssen.

Also statt:

markieren

Delphi-Quellcode:

			TMyDummyMethod = class

protected

  procedure Execute( input1: Integer; input2: TSomeClass; out output: Double );

end;

procedure TPacketHandler.Execute( const ACommandStr : string; input1: Integer; input2: TSomeClass; out output: Double );

begin

  fMethodDict[ACommandStr].Execute( input1, input2, output );

end;

zusammenfalten · markieren

Delphi-Quellcode:

			TMyMethodParameters = class

  input1: Integer;

  input2: TSomeClass;

  output: Double;

end;

TMyDummyMethod = class

protected

  procedure Execute(parameters: TMyMethodParameters);

end;

procedure TPacketHandler.Execute( const ACommandStr : string; input1: Integer; input2: TSomeClass; out output: Double );

var 

  Parameters: TMyMethodParameters;

begin

  Parameters:= TMyMethodParameters.Create(input2, input2, output);

  fMethodDict[ACommandStr].Execute(Arguments);

  Parameters.Free;

end;