Acronyme / Bücher über Konzepte zur Programm <> GUI Erstellung/Verbindung

[Milhouse van Hauten (Gast)]

Hallo zusammen,

ich suche nach Lehrbüchern bzw. Acronyme, die sich darum drehen, wie man 
sinnvoll eine GUI mit dem eigentlichen Programm verbindet.

viele Grüße!

[Pandur S. (jetztnicht)]

Worum geht es denn Java, C#, Python, Javascript, Php, Delphi, ..

Egal, bei allen Entwicklungsumgebungen gibt es Tutorials. Danach muss 
man sich alle zur Verfuegung gestellten Komponenten anschauen, und etwas 
rumspielen.

[Georg (Gast)]

Milhouse van Hauten schrieb:
> wie man
> sinnvoll eine GUI mit dem eigentlichen Programm verbindet.

Das macht man üblicherweise nicht so. Bei den meisten IDEs entwirft man 
als erstes das GUI, z.B. in Form einer Dialogbox, und weist dann den 
GUI-Komponenten zu, was sie tun sollen, wenn sie betätigt werden, z.B. 
angeklickt. Dazu sind diese Komponenten Objekte im Sinn der OO.

Georg

[Bernd K. (prof7bit)]

Georg schrieb:
> und weist dann den
> GUI-Komponenten zu, was sie tun sollen

Und sinnvoller Weise sollten sie nicht viel mehr tun als Dinge die 
direkt mit dem GUI zu tun haben (z.B. andere Buttons ausgrauen wenn ein 
bestimmter Zustand herrscht) die die eigentliche Arbeit von separaten 
möglichst eigenständig lebensfähigen Nicht-GUI-Komponenten erledigen 
lassen.

Zum Beispiel stell Dir vor ich will ein Tool schreiben das beim Kunden 
unkompliziert per Mausklick ein Firmware-Update über den Bootloader 
durchführt. Dann schreib ich mir (oder hab sie schon) eine Komponente 
die die ganze Kommunikation mit dem Bootloader abwickeln kann, die hat 
ein möglichst simples Interface mit nur wenigen Methoden, z.B. 
Connect(), UploadApp(FileName), UploadData(FileName), 
DownloadData(FileName), etc. und vielleicht noch ein paar Hooks um den 
Fortschritt oder Fehler anzeigen zu können und ich könnte diese 
Komponente dann ohne Änderung auch verwenden um damit mit wenigen Zeilen 
Code ein Kommandozeilentool zu bauen das das selbe tut wie mein 
angedachtes GUI-Tool, und in meinem GUI-Code mach ich nichts anderes als 
eine Instanz davon zu erzeugen, mich in die Hooks reinzuhängen um Sachen 
auf dem Bildschirm anzuzeigen und ein paar Methoden aufzurufen ums zu 
starten wenn der Benutzer die Buttons klickt. Dann kann ich beides 
voneinander unabhängig pflegen, austauschen, wiederverwenden, etc.

Natürlich halt ich mich nicht immer sklavisch daran, bei kleinen 
Wegwerf-Tools verletze ich diesen Grundsatz oftmals vorsätzlich oder aus 
purer Faulheit, wissend dass es eh nur ein Wegwerf-Tool ist, sowas ist 
ja in 20 Minuten zusammengeklickt und fertiggestellt mit ner 
ordentlichen RAD-IDE, aber bei größeren Sachen bei denen von vornherein 
abzusehen ist daß es womöglich mehr als nur dieses eine GUI-Tool geben 
wird das diese Funktionalität benötigt bau ich eine vollkommen separate 
eigenständige Komponente dafür, eine die womöglich ihrerseits wiederum 
aus mehreren ebenfalls wiederverwendbaren oder austauschbaren 
Komponenten besteht.

Stichworte zum Googeln für diese Trennung sind "Model" und "View" und 
evl. "Controller" wobei je nach RAD-System die Grenzen verwischen, 
gerade bei Delphi oder Lazarus oder generell bei Desktop-Klick-RAD-IDEs 
zieht es gerne die Aufgaben des Controllers ins View und man sollte da 
dann auch nicht auf Teufel-komm-raus gegen die Gepflogenheiten der IDE 
kämpen, aber das Model sollte man (und kann man auch immer sehr gut) auf 
jeden Fall separieren, das macht spätere Wiederverwendung zum 
Kinderspiel.

[Milhouse van Hauten (Gast)]

So dele,

hab jetzt das Acronym zugespielt bekommen, was ich brauchte: MVC => 
Model-View-Controller