Frage zur Struktur von GUI Programmen

Hallo

Ich habe schon ein paar kleine Programme mit Qt geschrieben, allerdings war es dort immer möglich alles in einer Klasse zu lassen, d.h. sowohl die GUI als auch die kleineren Rechnungen, die dann wieder an das GUI die ergebnisse schicken!
Nun würde ich gerne mehrere Klassen nutzen, allerdings habe ich dabei ein paar Fragen. Zum Beispiel:

Klasse "GUI" macht das graphische und soll auf Knopfdruck eine Klasse "Simulation" erzeugen in der dann Daten gespeichert und ausgewertet werden sollen. Nun soll aber die Klasse "simulation" auch ergebnisse in "gui" schreiben. Dafür muss aber im Header der Klasse Simulation auch die GUI klasse eingebunden werden. Und in der GUI die Klasse "Simulation". Dies erzeugt aber Probleme!

Wie kann man dieses Problem umgehen? Wie legt man generell Programme mit GUI an.
Vielen Dank für Hinweise und Tipps!

firefly

Verwende doch den signal slot mechanismus von Qt. Dadurch muss die Simualtions klasse die Gui Klasse nicht kennen. Die Gui Klasse verbindet sich einfach mit dem "Result" signal der Simulations klasse und erhält dadurch das Ergebnis und kann dieses dann anzeigen.

Hi,

Signale und Slots erscheinen zu Beginn viel schöner als sie in Wirklichkeit sind. Ich empfehle dir Signale und Slots nur zu verwenden wenn du dir damit viel Arbeit sparen kannst. Zu viele Signale und Slots machen den ganzen Code (bei etwas größeren Projekten) sehr sehr unübersichtlich.
Versuche dein Gui, falls du dort verschiedene Kategorien hast auch so im Code zu unterteilen, eine Klasse ist für die Übersicht nicht unbedingt von Vorteil. Ansonsten ist es sehr schwer ohne irgendeine Ahnung was du codest zu sagen wie du deinen Code in Klassen einteilen solltest

mfg

RHBaum

Klasse "GUI" macht das graphische und soll auf Knopfdruck eine Klasse "Simulation" erzeugen in der dann Daten gespeichert und ausgewertet werden sollen. Nun soll aber die Klasse "simulation" auch ergebnisse in "gui" schreiben. Dafür muss aber im Header der Klasse Simulation auch die GUI klasse eingebunden werden. Und in der GUI die Klasse "Simulation". Dies erzeugt aber Probleme!

Typisches C++ Design-"Problem"
Man nutzt generell 2 Mittel, um Typabhaengigkeiten zu reduzieren, bzw aufzulösen.
- Forward-Deklarationen
- Interfaces

In der Praxis, zumindestb bei groesseren Projekten, trennt man sauberer. Da gibt es meist die GUI (keine einzelne Klasse, sondern eine Unmenge von klassen) Und die Business-Logic (Oft gibts noch mehr Teile, Daten-Persistenz(Datenbank-Schicht) z.b.).

Da die GUI meist die Logic bedient, richtet sich die GUI nach der Schnittstelle der Business Logic. Zur Schnittstelle der Business-Logic gehoert dann meist nicht nur ein Interface zum Veraendern der Logic, sondern auch ein Interface um veraenderungen(Events) mitzubekommen (Listner-Interfaces oder aehnliches). Die GUI implementiert dann meist das vorgegebene Interface.

Damit ist die Business-Logic frei von jeglichen Typen der GUI, die GUI aber wiederum "nur" abhaengig vom Interface der Logic, was aber nicht zu vermeiden ist, weil sie "bedient" ja die Logic irgendwie.

@SOSWeAreSinking
Das Signal-Slot Konzept ist aber auch mächtiger wie es aufn 1. Blick ausschaut.
Es kann auch in Business-Logic Schichten Sinn machen, wenn man Ereignisse generalisieren will. Am Ende ist das Signal-Slot konzept eigentlich ne ziemlich generische und trotzdem systemnahe implementierung des Command-patterns (Design Pattern-Verhaltensmuster)
Und es gibt Signal-Slots ned nur in der Qt, sondern auch Losgeloest jeglicher GUI (z.b. boost.signals)

Verwendendet man GUI-SIgnale in der Business-Schicht direkt, klar bricht man die Trennung auf, und es kommt zu unsauberen Design. Wenn beide seiten aber Ihr eigenes Signal-Slot Konzept haben, und man diese Über eine Vermittlerschicht verbindet, ist das Design auch wieder "sauber".

Beispiele sind z.b. wenn man sein Programm auf eine Prozesstechnische trennung(Logic lauft z.b. als daemon, die GUI ist ein eigenstaendiges Programm nur zur bedienung des deamons bei bedarf) von Logic-und GUI vorbereiten will. Dann braucht man ein total typunabhangiges eventbasiertes Konzept. Realisiert man die Schnittstelle rein ueber ein Signal-Slot konzept, kann man später die richtige Trennung recht leicht durch zwischenschieben eines eventbasierten IPC-Mechanismus ins Signal-SLot konzept realisieren. Geeignete mechanismen waeren klar, RPC-calls oder DBus, früher war Corba beliebt, COM soweiso ...

Ciao ...