Vielleicht ist das genau das Problem: In der Praxis geht es durchaus, so wie Du das beschreibst.
Zumindest erstmal ...
Auch wenn Du Deinen Fokus lieber auf die Praxis legst, möchte ich ein wenig Theorie beisteuern:
Eine Methode sollte einen definierten Zweck haben. Und zwar genau einen. Aus diesem Zweck ergibt sich in den meisten Fällen auch ein brauchbarer Name für die Methode. Hier hat man auch eine schnelle Möglichkeit zur selbstkritischen Kontrolle: Wenn einem auf Teufel komm raus kein brauchbarer Name für eine Methode einfallen mag, so ist das ein ganz deutliches Indiz dafür, diese Methode zu überdenken und den Code ggf. anders zu strukturieren.
Button1.Click() ist die Methode, die aufgerufen wird, wenn die zugehörige Schaltfläche gedrückt wird. Fertig aus. Diese Methode hat eine sehr enge Bindung zu Deiner Programmoberfläche und man kann sie als Teil derselbigen ansehen. Der Klick auf den Button soll ja etwas auslösen und das sollte diese Methode deligieren. Wenn jetzt in Deinem Datenmodell etwas verändert werden soll, zum Beispiel eine Variable gesetzt werden soll, dann hast Du eine Methode, die sich darum kümmert und etwaige Plausibilitäts-prüfungen vornimmt. Das aber hat mit dem Button nichts mehr zutun. Die Variable könntest Du auch ändern, wenn Dein Programm zum Beispiel über ein Script gesteuert wird. Auch dann müsstest Du ja etwaige Plausibilitäten rund um diese Variable prüfen. Das kannst Du nur dann erreichen, wenn Du den Code kapselst. Alleine durch die Kapselung von Code holst Du Dir auch keine negativen Seiteneffekte ins Haus.
Nun kannst Du jetzt sagen: "Ach was, läuft doch" - und hast in Deinem Fall sogar Recht damit. Mir ist es gleich, wie Du Deinen Code schreibst und ich will jetzt nicht sagen "Du musst, Du musst, Du musst...". Aber als Denk-Anstoß solltest Du das mitnehmen. Ich bin ja nicht der einzige, der so denkt. Das Ding is', dass sich diese Denkweise in der Software-Entwicklung weitgehend etabliert hat.
Stichworte wären: "Kopplung von Modulen", in diesem Zusammenhang auch "Trennung von
GUI und Programm-Logik" oder aber das gute alte "Model-View-Controler"-Prinzip. Selbst verständlich steht es Euch frei, zu entwickeln, wie Ihr mögt - aber unternehmt bitte nicht den aussichtslosen Versuch, o.g. Konzepte mit einem Satz allgemeingültig wegzuwischen.
Daniel R. Wolf
mit Grüßen aus Hamburg