- 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