Wann Signale und Steckplätze zu verwenden und wenn nicht

Question

Wir verwenden Qt, die Signale und Steckplätze bietet, die ich wirklich bequem finde. Mit großer Macht kommt jedoch große Verantwortung und ich denke, es ist sehr einfach, diese Funktion zu missbrauchen.

Gibt es Best Practices für die Verwendung von Signalsteckplätzen? Es fällt mir schwer, auf diese Weise allgemeine Richtlinien zu finden. Einige Fragen (ich habe klare Meinungen darüber, aber das stimmen nicht alle Mitglieder meines Teams zu):

Ist es in Ordnung, Signale zu verwenden, um Fehler zu melden?

Ist es in Ordnung anzunehmen, dass ein Signal verarbeitet wird?

Können Signale zum Einleiten von Aktionen verwendet werden? Z.B. signal displayInfoScreen() muss von einem Slot bedient werden, der einen Info-Bildschirm anzeigt.

Andere Meinungen darüber, wann Signale verwendet werden sollen/sollten, sind sehr willkommen!

Answer 1

Ist es in Ordnung, Signale zu verwenden
Fehler melden?

Ja, siehe zum Beispiel QFtp, wo das Done-Signal einen Status trägt. Es trägt nicht den tatsächlichen Fehler, nur die Information, dass ein Fehler aufgetreten ist.

Ist es in Ordnung anzunehmen, dass ein Signal behandelt wird?

Nein. Der Absender kann niemals davon ausgehen, dass Ihre spezielle Anwendung davon abhängen kann. Zum Beispiel muss die QAction, die Datei - Neu darstellt, behandelt werden, damit die Anwendung funktioniert, aber dem QAction-Objekt ist das egal.

Können Signale verwendet werden, um Aktionen einzuleiten? Z.B. signal displayInfoScreen() muss von einem Slot behandelt werden, der einen Info-Bildschirm anzeigt.

Wieder ja, zum Beispiel das QAction-Objekt. Wenn Sie jedoch Komponenten wiederverwenden möchten, müssen Sie darauf achten, dass die tatsächliche Klasse nicht davon abhängt.

Answer 2

Ist es in Ordnung anzunehmen, dass ein Signal verarbeitet wird?

Nein, ist es nicht. Signale sind Feuer-und-Vergessen-Dinge. Wer sich mit einem Signal verbindet und was es tut, sollte nicht die Angelegenheit des Emitters sein.

Answer 3

Signale/Slots (auch als Ereignisse bezeichnet) sind eine gute Methode, um die Kopplung zwischen Objekten zu entfernen.

Zum Beispiel, anstatt Ansichten zu haben, die verstehen, wie das Modell funktioniert, und wenn sich das Modell ändert, "hören" sie dem Modell zu. Das Modell ist verantwortlich zu sagen, wann es sich ändert, was sich ändert.

Das Problem mit Ereignissen ist, wenn Sie Ihre Ereignisse mit Clientanforderungen entwerfen. Zum Beispiel sollten Sie kein Signal displayInfoScreen haben, weil es etwas von Objekten annimmt, die dieses Signal verwenden. Stattdessen sollte es infoChanged sein und das InfoScreenDisplayer hört auf diese Signale, um es auf Bildschirm anzuzeigen. Wenn Sie möchten, können Sie später eine InfoTweeterPoster hinzufügen, die die Informationen auf Hochtöner posten, wenn sie sich ändern.

Answer 4

Signale und Steckplätze sind leistungsstark, da Objekte entkoppelt werden. Sie können nicht davon ausgehen, dass ein Signal einen Steckplatz angeschlossen hat, wie zuvor beantwortet.

Ein Hauptnachteil des signal-/schlitzbasierten Designs ist, dass Sie sehr leicht die Logik der implementierten Spur verlieren können, da eine Aktion eines Objekts andere Aktionen eines anderen Objekts auslösen kann, das mit einem Signal verbunden ist. Es ist viel einfacher, unerwünschte Nebenwirkungen, rekursive Anrufe usw. zu haben.

Answer 5

Ist es in Ordnung, Signale zu verwenden, um Fehler zu melden?

Ja, aber ich würde im Allgemeinen diese Situation abhängig machen. Wenn der Fehler asynchron auftreten könnte, ist ein Signal, das dies anzeigt, definitiv richtig. Wenn der Fehler nur auftritt, wenn Client-Code eine bestimmte Funktion aufruft, sollte der Fehler in der Antwort von dieser Funktion sein, nicht als ein Signal. Es gibt jedoch eine Vielzahl von Situationen dazwischen, die von Fall zu Fall durchgeführt werden können.

Signal-Slot-Mechanismen können auch die Cross-Thread-Kommunikation erleichtern (was möglicherweise als asynchroner Fall betrachtet wird), und ich werde sie für diesen Zweck verwenden (Fehler oder Nein).

Ist es in Ordnung anzunehmen, dass ein Signal verarbeitet wird?

Signale sind (philosophisch) entworfen, um anzuzeigen, dass etwas passiert ist. Wie andere gezeigt haben, ist es nie eine gute Idee, anzunehmen, dass ein Signal mit einem Slot oder sogar nur mit einem anderen Slot übereinstimmt.

Können Signale zum Einleiten von Aktionen verwendet werden? Z.B. signal displayInfoScreen() muss von einem Slot bedient werden, der einen Info-Bildschirm anzeigt.

Signale können zum Einleiten von Aktionen verwendet werden, aber wahrscheinlich nicht in der Art, wie Sie denken. Das Signal zeigt an, dass foo passiert ist. Wenn der Code, der Ihre Klasse überwacht, entscheidet, dass wenn foo passiert, sollte ein Dialog angezeigt werden, dann wurde das Signal verwendet, um diese Aktion zu initiieren. Es liegt jedoch in der Regel nicht in der Verantwortung der Klasse, die das Signal aussendet, um sicherzustellen, dass die richtige Aktion stattfindet, da sie nicht dafür verantwortlich ist. (Wenn ja, dann sollte es Teil der gleichen Klasse sein, und kein Signal erforderlich wäre.)