Seite 1 von 1

Klassen - Designfrage in Verbindung mit Multithreading

Verfasst: 26. Januar 2008 09:59
von methusalem
Moin,

hatte ja gestern schon in dem QextSerialPort Thread gefragt. Da ich es aber eher für ein Multithread Problem halte, hier noch mal eine allgemeiner formulierte Frage.

Es soll ein Programm geschrieben werden, welches über ein Hauptfenster den COM Port und die Verbindungsparameter erfragt. Nach klick auf den Button "Open Port" wird eine Verbindung zu dem gewählten COM Port aufgebaut und alle Daten die dort angeliefert werden im Hauptfenster ausgegeben. Ein klick auf den Button "Close Port" schließt die Verbindung nun wieder.

Es gibt nun folgende Klassen:
1.) Hauptfenster -> Die GUI
2.) QextSerialPort -> der COM-Port
3.) readThread -> der Thread zum lesen aus dem COM-Port

Meine Frage: In welcher Klasse würdet Ihr das Object der Klasse readThread erstellen? Ich bin ja der Meinung, das dies in der GUI Klasse (Hauptfenster) passieren müsste. Der readThread würde dann einen Pointer bekommen um darauf zuzugreifen. Würde man das Objekt in der Klasse readThread erstellen, könnte ja auch nur diese Klasse auf den PORT zugreifen. Und das wäre irgendwie blöd, wenn man später aus der GUI auch noch Befehle an den COM-Port senden möchte.

Ich hoffe man versteht, was ich meine. Die Sache mit dem COM Port soll auch nur als Beispiel dienen. Man kann das beliebig ändern. Es geht mir um die Frage des Klassendesigns in dem Fall, das ich ein Objekt nicht nur in der Thread-Klasse benötige.

Verfasst: 26. Januar 2008 11:08
von solarix
Im Softwareentwurf gibt es meist viele verschiedene Lösungen. Leider kann dir daher niemand eine allgemeine Regel für den Fall "das ich ein Objekt nicht nur in der Thread-Klasse benötige." schreiben.
Das Klassendesign hängt ganz davon ab, was für eine Rolle dieses Objekt in deiner Applikation übernimmt.

In deinem Beispiel würde ich z.B. das Objekt "QextSerialPort" in der Thread-Klasse kapseln und sämtliche Operationen darauf (lesen/schreiben) über die Thread-Klasse abwickeln.
Wenn du die GUI für ein spezielles Gerät schreibst, würde es sich anbieten, dass die GUI überhaupt keinen Kontakt zur Hardware-Schnittstelle hat, sondern nur mit einem abstrakten Objekt (z.B. "TemperaturSensor") kommuniziert. Dann hättest du drei Klassen: die GUI, die Threadklasse für allgemeine Kommunikation via RS232 und (z.B.) die "Sensor"-Klasse, welche das serielle Protokoll für das externe Gerät kennt.