Das klingt nach dem magic pushbutton-anti-pattern. Das ist eine Unsitte, die bei Entwicklungsumgebungen mit eingebautem Formulareditor (wie VB oder Delphi) häufig vorkommt: Man schreibt in eine Callbackmethode eines Bedienelements rein, was das Bedienelement tut.Zitat von Davias
Auf den ersten Blick wirkt das harmlos - immerhin soll ja definiert werden, was der Knopf tut! Tatsächlich stimmt das aber nicht. Es soll ein Verhalten definiert werden, das durch den Knopf ausgelöst wird. Das Verhalten könnte aber auch auf einem anderen Weg ausgelöst werden. Man sollte die eigentliche Programmlogik immer in eigene Methoden auslagern, aus mehreren Gründen:
Zuerst ist da der offensichtliche Grund - vielleicht willst du später mal die gleiche Funktionalität zusätzlich über ein Menü oder sonstwie verfügbar machen. Das geht nur dann sauber, wen der Kram in seiner eigenen Methode liegt. Copy and paste ist nicht dein Freund.
Dann ist noch das Wartbarkeitsproblem. Wenn du später was an deinem Code ändern willst, mußt du auch wissen, was er macht. Nach einigen Monaten hat man das nicht mehr im Kopf und da kommt es schon vor, daß man rausfinden muß, was eine bestimmte Methode überhaupt tut. Es hilft dabei immens, wenn die Methode exportToCSV() heißt und nicht Button13.onClick().
Außerdem wird die Trennung von Präsentation (GUI) und Logik (was das Programm tut) generell als gute Idee angesehen. Im Idealfall sollte man das GUI komplett rausreißen und neu machen können, ohne daß das die Logik weiter interessiert.
Du bist natürlich noch neu*, aber ich empfehle dir, dir Dinge wie Modularisierung und code reuse möglichst früh zu verinnerlichen. So gewöhnst du dir schlechte Gewohnheiten gar nicht erst an - die sind teilweise nämlich wirklich schwer wieder loszuwerden.
* Beim Programmieren, nicht im Forum. Nur, damit es da keine Mißverständnisse gibt.
Zitieren