Zusammenspiel Oberfläche mit OOP gedanken

@Gregor: Im Modell würde ich dann Interface.printMessage aufrufen, aber wie erfährt die View(GUI) das sie was tun muss?

Und wie geht es mit dem umgekehrten weg. Die View übermittelt daten an das Modell. Ruft sie Direkt die Modell Funktionen auf oder geht das auch über eine zwischen Schicht?

Danke!

Pedro

Cosmixx

Hallo,

im Prinzip ist Gregors Ansatz schonmal korrekt. So kann die Ausgabe auf eine beliebige Art erfolgen.
Bei größeren Sachen ist aber wie Du schon sagst aus meiner Sicht eine weitere "Schicht" nötig, meist Controller genannt. Dieser wird über jede Änderung (z.B. von Eingabewerten) von der View aufgerufen, ändert die Dtaen des Modells und benachrichtigt die GUI, sich "upzudaten". Denn normalerweise gehören in die Datenhaltung keine Aufrufe wie printMessage().

Gregor

Cosmixx schrieb:

Bei größeren Sachen ist aber wie Du schon sagst aus meiner Sicht eine weitere "Schicht" nötig, meist Controller genannt. Dieser wird über jede Änderung (z.B. von Eingabewerten) von der View aufgerufen, ändert die Dtaen des Modells und benachrichtigt die GUI, sich "upzudaten". Denn normalerweise gehören in die Datenhaltung keine Aufrufe wie printMessage().

Ja, natürlich. Ich bin bei meinem Beitrag nicht von einem "Model-View" Konzept ausgegangen, sondern von einem "Model-View-Controller"-Konzept. Die printMessage-Methode befände sich da im View-Teil und würde vom Controller aufgerufen werden. Den Controller habe ich da oben einfach mal als "Programmlogik-Teil" beschrieben. Das "Model" spielt da soweit noch gar keine Rolle. Das ist "auf der anderen Seite" mit dem Controller verbunden.

Gregor

Pedro_15 schrieb:

Und wie geht es mit dem umgekehrten weg. Die View übermittelt daten an das Modell. Ruft sie Direkt die Modell Funktionen auf oder geht das auch über eine zwischen Schicht?

Auch das würde über den Controller ablaufen.

Gregor

Sovok schrieb:

halt ich für viel zu umständlich für sowas simples

mit globaler funktion mein ich

void Print ( const char* sMsg )
{
  if ( g_hFenster != NULL )
  { 
    g_hFenster->Print ( sMsg ); // g_hFenster = globales handle auf das fenster
  }
  else
  {
    cout << sMsg << endl;
  }
}

Sovok: Das führt zu unwartbarem Code, weil du die Funktionalitäten vermischt. Von dieser Herangehensweise rate ich definitiv ab. Wenn du an dem Verhalten der GUI etwas ändern willst, dann ist es äußerst schlecht, wenn du andauernd mit Konsolen-Code konfrontiert wirst.

Sovok

Gregor schrieb:

Wenn du an dem Verhalten der GUI etwas ändern willst, dann ist es äußerst schlecht, wenn du andauernd mit Konsolen-Code konfrontiert wirst.

inwiefern "andauernd"
ich seh die funktion als global
d.h. sie könnte auch in einer bibliothek stecken

dem aufrufenden ist es egal wie die ausgabe intern gelöst ist, er will einfach nur die ausgaben anzeigen

sinnvoll wäre das z.b. damit auch ausgaben gemacht werden können bevor das fenster erzeugt und nachdem es gelöscht wurde

phlox81

Sovok schrieb:

Gregor schrieb:

Wenn du an dem Verhalten der GUI etwas ändern willst, dann ist es äußerst schlecht, wenn du andauernd mit Konsolen-Code konfrontiert wirst.

inwiefern "andauernd"
ich seh die funktion als global
d.h. sie könnte auch in einer bibliothek stecken

dem aufrufenden ist es egal wie die ausgabe intern gelöst ist, er will einfach nur die ausgaben anzeigen

sinnvoll wäre das z.b. damit auch ausgaben gemacht werden können bevor das fenster erzeugt und nachdem es gelöscht wurde

Eine GUI hat i.d.R. mehr als ein Fenster, also bräuchte man dann entsprechend viele
Funktionen, zu dem bei dir noch hinzu kommt, das die Consolenversion GUI Variablen
hat, diese aber nicht braucht. Da macht es schon sinn, einen Controller dazwischen
zu schalten, der dann über ein Interface die GUI / Console steuert.

bin davon ausgegangen, dass es nur um die textausgabe ging
klar falls es mehrere features sind die geswitcht werden sollen ist die lösung mit der basisklasse sinnvoller aber bei kleinen einzelaufgaben wirkt zuviel oop eher unübersichtlich

Gregor

-Sovok- schrieb:

bin davon ausgegangen, dass es nur um die textausgabe ging
klar falls es mehrere features sind die geswitcht werden sollen ist die lösung mit der basisklasse sinnvoller aber bei kleinen einzelaufgaben wirkt zuviel oop eher unübersichtlich

Dann war das wohl ein Missverständnis. Ich gehe bei solchen Fragen immer davon aus, dass nach einer allgemeinen Herangehensweise gefragt wird, die man auch bei größeren Projekten durchführen kann. Ein Beispiel, das irgendwo in der Fragestellung gebracht wird, wird meistens nicht die wirkliche Komplexität des eigentlichen Problems wiederspiegeln.

rüdiger

Heutzutage programmiert man keine GUI mehr im Code, sondern man erstellt seinen Code, bastelt sich eine GUI in einem GUI Editor und erzeugt dann Datenbindungen zwischen der GUI und dem Code.

Schau dir zB Adobes Adam & Eve oder Mozillas XUL & XBL an.

So trennt man Layout und Inhalt.

Hallo Ihr,

vielen Dank für die schnellen Antworten.

Habt Ihr für mich ein kleines Beispiel Projet wo man das mit dem Modell, View und dem Controller sehen kann?

Ein Tutorial über diese Thema würde mir auch weiter helfen.

Ich brauche einfach einen Startpunkt, noch ist bei mir alles unklar was wo und wie Implementiert wird und wie die Kommunikation erfolgt.

Vielen Dank für die hilfe!

Pedro