klassendesign

hi,

ich habe ein problem:

ich will eine opengl-anwendung schreiben (NEIN! nicht verschieben.), und habe dafür eine fensterklasse

class window

, die mir die ganze x-initialisierung abnimmt, und die eingehenden signale (tastatur, maus etc.) in einer noch nicht definierten form weiterleiten kann. (wird u.u. auch mal für winapi mit derselben schnittstelle geschrieben. nur am rande.)

jetzt kommt die klasse dazu, die die eigentliche arbeit macht. also, user-eingaben verarbeiten, interne logik verwalten, auf den bildschirm zeichnen. nennen wir sie der einfachheit halber

class g

jetzt die frage: wie soll das ganze aussehen: soll "g" einen member "window" haben, weil ja das fenster quasi zur anwendung gehört? dann müsste die eventschleife innerhalb von g sein. außerdem: wie soll dan das zeichnen vonstatten gehen? wenn ich das irgendwie so löse:

g::draw()
{
    gl_blablazeichnen(...);
    m_window.flush_drawn_stuff_to_screen(); 
}

dann, sieht das irgendwie blöd aus. weil das zeichnen an sich ja gar nicht zur logik gehört, sondern zu "window", aber irgendwie auch nicht.
oder soll g ein member von window sein, weil ja die anwendung _im_ fenster ist? dann würde die sache mit dem zeichnen schön der hierarchie folgen ("fenster sagt der anwendung: zeichne jetzt!") das ist aber anderweitig recht unintuitiv, da die anwendung ja "über" dem darstellenden fenster stehen sollte.

eine weitere lösung - und zwar mit callbacks - habe ich mal ausgeschlossen, weil die nicht wirklich anders als die zweite ist, nur umständlicher.

wer weiß rat?

<edit><b>-Tags entfernt!</edit>

hallo
hmm was es auch werden mag, ich versuchs mal:

würde die klassen trennen und nicht die eine als member der anderen instanzieren. die eigentliche applikation als controller über alles setzen. weiter eine kernel-klasse definieren für die logik. vom window/gui aus nachrichten an die app senden, die lässt dann die kernel rechnen. die berechenten sachen als rohdaten (x/y-pos etc..) oder als objekte zurücksenden.
das window kann dann auf befehl die ganzen sachen darstellen.
dazu musst Du die entsprechenden funktionen wie g.send_message() und window_flush_drawn_stuff_to_screen()
entweder public oder
die controller klasse als friend definieren.

hoffe das ist irgendwie logisch und sinnvoll.

ok, danke, ich werd mir dann mal was überlegen

Spacelord

Hallo,
wenn jetzt schon feststeht dass Teile der Implementierung später mal durch andere ersetzt werden sollen(z.B. für die geplante Windowsportierung) dann schau dir mal das hier an: http://www.mitp.de/imperia/md/content/vmi/1347/4.pdf

MfG Spacelord

aaah, danke, das ist wirklich interessant. aber ich glaube, das ist für meine bedürfnisse schon etwas zu.. abstrakt. ich will ja schließlich keine bibliothek programmieren.