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!
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.
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
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.
:
Bearbeitet durch User
So dele, hab jetzt das Acronym zugespielt bekommen, was ich brauchte: MVC => Model-View-Controller
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.