Qt信号和插槽 - 它们仅用于GUI还是整个应用程序架构？

Question

我很好奇 - Qt的信号和插槽（委托模式？）仅用于GUI回调，或者它们非常好并且用于整个应用？我的意思是，将应用程序拆分为小型，自包含的对象（类）并通过信号和插槽进行互连是否更好。如果是这样，从信号返回值的推荐方法是什么（用于返回某些东西的类似请求的信号），因为Qt的信号返回值被忽略。

Answer 1

QT的信号和插槽不用于从reciver返回值。它们是一种严格的单向沟通机制。

接收方实际上可能处于完全不同的线程中，在发送方emit调用返回后，从队列接收信号。

至于将它用于除GUI之外的任何东西..如果它适合那里，你可以在任何适合的地方使用它们。为什么单独将GUI作为特殊的东西？

Answer 2

信号和插槽是实现observer pattern的一种方式。在使用观察者模式的任何地方（例如减少耦合），您也可以使用信号和插槽。

Answer 3

您可以将它们用于所有事情。

它们可以很好地用于实现网络代码

Answer 4

信号和插槽用于模拟库级别对象之间的消息传递（因为C ++不支持像Smalltalk那样的消息），所以你可以在任何你想让对象相互通信的地方使用它们（要么通过一些周围的数据或激活的东西...等）。我几乎把它们用于了所有的东西，他们工作得很好，我得到的唯一问题是并发代码，我有多个线程使用信号和插槽相互通信它真的很糟糕（我需要实时处理消息）因为插槽的执行不是立竿见影的。

我认为你不能使用信号来返回一个值（你不应该）导致信号被发送到其他对象

  

/ *如果您有特定问题   你想解决尝试解释它   也许有办法解决它   * /

Answer 5

Qt的信号和插槽实现相当灵活。它绝对不限于GUI元素。甚至还有一个单独的排队信号传递机制，可以让您将信号从一个线程传递到另一个线程。

如果您真的认为需要，可以在信号内传递引用或指针，这样可以将信息传递回发射对象。但是我会小心读取信号以及何时执行相应的插槽。接收器上的信号发射和执行有两种模式，立即和排队。如果您要跨线程发信号，则需要排队，然后立即发出返回。

在实践中，我注意到信号和插槽连接的大型网络可能有点难以调试，因为您现在正在创建与对象派生和包含的单独结构。

Answer 6

特别是在回复值时，我没有感觉到Qt的信号和插槽是一个很好的来回机制。正如其他人所提到的，它们在观察者模式/角色中的表现非常好。如果你考虑一下，返回值可能存在问题......例如当你有一个以上的槽连接到一个信号时会发生什么，它们各自返回不同的值？在SigC ++和Boost :: Signals库中也会出现同样的问题，每个库都有一个（不同的？）机制来处理它，或者至少弄清楚你会得到什么。

如果你真的需要一个返回值，我发现有两种相对不错的方法来管理它。第一种是使用Qt的事件机制来请求数据，然后将请求的数据作为响应传回。请注意，事件没有内置的响应方式，因此您需要扩展QEvent才能处理这种情况。我们实际上在我的工作申请中做了相当多的工作。当您需要异步机制时，它对于线程应用程序非常有效。这种方法的缺点是请求者需要知道它正在请求数据的对象（为了发送事件）。响应对象不需要知道任何请求以及如何发送回响应，响应通常被编码到请求中。请注意，这几乎与观察者模式相反。

第二种方法是将仿函数对象传递给需要能够请求数据的对象。这有一个很好的抽象函子库可以很好地工作，它允许你封装对象和函数，比如前面提到的SigC ++或Boost :: Signals。这也适用于需要立即响应的情况 - 运行仿函数的运算符，并在继续处理函数之前返回一个值。这也允许你编写一个类似于信号/槽机制的对象，其中需要函数（信号）返回值的对象不需要知道函子（信号的连接）的位置。制作，或来自。它只是在必要时运行仿函数。