[Design] 2 Fragen zum Design von Parameterübergaben

[silver-moon-2000]

Hallo zusammen,

wiedermal sorry für den seltsamen Titel, aber mir ist nichts besseres eingefallen.

Ich stelle mir gerade die Frage, wie ich meine Programme "etwas" übersichtlicher gestalten kann. Momentan betrifft das hauptsächlich die Übergabe von Parametern/Funktionsaufrufe.
Dazu hätte ich gleich zwei Fragen, wie Ihr an diese Fragestellungen herangeht:

Fragestellung 1
Angenommen, ich habe eine Aktion in der GUI , welche über ein Event (z.B. ButtonZumWarenkorbHinzufuegenPress) an die darunterliegende Logik weitergegeben wird.
Die Logik reagiert darauf mit einer Methode ReactToGUIButtonZumWarenkorbHinzufuegenPress.

Delphi-Quellcode:

constructor TFooLogik.Create;
begin
[...]
  FGUI := TFooGUI.Create(nil);
  FGUI.OnButtonPress := ReactToGUIButtonZumWarenkorbHinzufuegenPress;
end;

Im Zuge des ButtonPress seien nun einige Sachen zu berechnen.
Wo/wie führt Ihr diese Berechnungen aus? Wo ist es sinnvoller?
- in der Methode ReactToGUIButtonZumWarenkorbHinzufuegenPress selbst

Delphi-Quellcode:

procedure TFooLogik.ReactToGUIButtonZumWarenkorbHinzufuegenPress(_sender : TObject);
begin
  //fügt aktuell ausgewähltes Item zum Warenkorb dazu
end;

- ruft ReactToGUIButtonZumWarenkorbHinzufuegenPress eine weitere Methode auf, die die Berechnung ausführt?

Delphi-Quellcode:

procedure TFooLogik.ReactToGUIButtonZumWarenkorbHinzufuegenPress(_sender : TObject);
begin
  AddCurrentItemToBasket;
end;

procedure TFooLogic.AddCurrentItemToBasket;
begin
  //fügt aktuell ausgewähltes Item zum Warenkorb dazu
end;

Für die zweite Variante spricht, dass die Berechnungen eben in einer dedizierten Methode AddCurrentItemToBasket aufgerufen werden, und nicht direkt in einer Methode ReactTo..., die man als Teil des Eventhandlers bezeichnen könnte.
Meiner Meinung für die erste Variante spricht, dass ich mir in der zweiten Variante für jedes Event eine weitere Methode einhandle, was bei einigen Buttons, Radiogroups etc. langsam unübersichtlich wird. Zumal dann, wenn man (wie ich finde), schon in den ReactTo... Methode sprechende Namen verwendet.

Ich bin mir sicher, dass es, wie leider so oft, keine in Stein gemeißelte Variante gibt, aber es würde mich doch interessieren, ob die eine Variante gegenüber der anderen signifikante Vor-/Nachteile hat.

Fragestellung 2
Gegeben sei ein Aufruf einer Funktion/Prozedur/Methode, die zur Durchführung einige Parameter braucht, sagen wir einfach mal 5-6 Parameter.
Weiter seien "Datensammel"-Objekte gegeben, in denen diese nötigen Paramter drinstecken und die diese ötigen Informationen "bündeln".
Wie sieht bei Euch nun die Paramter-Übergabe aus? So:

Delphi-Quellcode:

//Aufruf so:
CrawlWebsite(FItem.url, FItem.name, FItem.shopID, FStatus.status, FStatus.updateFlag);

procedure CrawlWebsite(_url, _name : string; _shop : Integer; _status : TShopStatus; _updateFlag : Boolean);
var temp : string;
begin
  if IsValidURL(_url) then
  begin
    temp := Copy(_name, 1, Pos('#', _name));
    [...]
  end;  
end;

oder so:

Delphi-Quellcode:

//Aufruf so:
CrawlWebsite(FItem, FStatus);

procedure CrawlWebsite(_item : TShopItem; _status : TShopStatus);
var temp : string;
begin
  if IsValidURL(_item.url) then
  begin
    temp := Copy(_item.name, 1, Pos('#', _item.name));
    [...]
  end;  
end;

Die Objekte TShopItem und TShopStatus sind dabei ewesentlich umfangreicher als die hier benötigten Infos, bündeln also deutlich mehr Werte.
Ich persönlich bin kein Freund der zweiten Variante, da man (ob nun absichtlich oder durch Nachlässigkeit) in CrawlWebsite nun die in FItem und FStatus gespeicherten Werte verändern kann.
Daher übergebe ich eigentlich immer nur die parameter, die für eine Methode nötig sind, auch wenn das teilweise zu (deutlich) längeren Parameterlisten führt.

Wie haltet Ihr es hier?

Ja, ich weiß, ich und meine dämlichen Fragen... aber wo ich das doch so gerne wissen will

[r2c2]

- Die GUI sollte von der Logik abhängen. Nicht umgekehrt. Du willst die Darstellung ändern können, ohne, dass davon die Fachlogik beeinträchtigt wird. Demnach sollten beide in getrennten Klassen sein und die GUI-Klasse (=Formular) sollte die Fachlogik-Klasse(n) benutzen. ==> SRP
- Demnach: Ja man sollte das trennen und die Ereignisbehandlungsroutine ruft eine Methode auf, die die Fachlogik implementiert. Das ist anders als Variante 1, aber auch nicht ganz Variante 2.
- Dein Argument war, das das unübersichtlich wird. Wird es nicht, wenn du es richtigerweise in zwei Klassen teilst. Ereignisbehandlung in der Form-Klasse und Fachlogik in anderen.
- Des weiteren könnte man meinen, dass dann in der Ereignisbehandlungsroutine nichts weiter steht als ein Methodenaufruf. Es gibt aber noch mehr, was man da tun kann (und ggf. sollte): Exceptions fangen und behandeln, Fehlermeldungen anzeigen, Buttons aktivieren/deaktivieren, ggf. ein Logfile schreiben... letztendlich die Benutzerführung realisieren.
- 5-6 Parameter sind zu viele. ==> MIMC, Long Parameter List
- Parameter, die man logisch gruppieren kann, sind ein Smell. Nennt sich Data Clumbs.
- Demnach: Variante 2 ist besser. Frag dich insbesondere was man besser lesen kann.
- Oft sind lange Parameterlisten ein Zeichen dafür, dass man besser ne Klasse draus machen sollte. TWebCrawler oder so.
- Wenn du objektorientiert programmieren willst, solltest du auch mit Objekten hantieren und nicht mit Strings und Integers. Sowas wie _shop : Integer ist schonmal merkwürdig.
- Boolean-Flags als Parameter sind ebenfalls ein Smell. ==> FlagArgument. LC.
- ...


mfg

Christian