R
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 ...