Boost::Signals 的意义何在？答案

【问题标题】：What is the point of Boost::Signals?Boost::Signals 的意义何在？
【发布时间】：2010-11-25 03:43:14
【问题描述】：

首先，我是一个绝对的编程初学者，所以不要太取笑我。
我见过的唯一信号是 GUI 工具包，而 GUI 工具包都带有自己的信号。那么，Boost:Signals 甚至可以与这些 GUI 工具包一起使用吗？这是个好主意吗？信号还有哪些其他应用？

【问题讨论】：

【解决方案1】：

Signals 是一种事件消息传递实现，很像 Smalltalk/Objective C Messages 或各种其他（例如 C#）语言中的 Events。

您可以将它们用于各种任务，请查看Observer Pattern

为什么要使用观察者模式？

好处主要是组织性的，当您使用大型应用程序时，应用有助于保持开发团队一致性的重用模式非常重要。

当特定模式的实现成为事实上（或接近）时，它特别有用，因为这意味着新团队成员的准备时间可能会加快，不仅如果他们以前使用过该实现，而且因为实施的普及意味着有广泛的资源和文档可用于加速学习。

从纯代码的角度来看，所有模式都显得臃肿，但是当您开始了解软件开发中超过 60% 的成本都在维护生命周期中时，增加代码以获得一致性是非常值得的.

另一个好处是有助于软件重用，根据实现的风格，观察者模式可以帮助模块化和解耦类。我认为这也是一种组织优势，因为不同的团队可以更轻松地构建组件，或者仅仅是因为组件更容易替换。

【讨论】：

观察者模式看起来就像是调用方法的额外代码。似乎我可以只调用我想要的对象的方法，而不是创建一个信号并让对象捕获它，然后启动它的一个方法。也许我错过了什么？
@Patrick，对于观察者模式，您想知道为什么要调用 notify()，向其传递一些消息，从而让 notify() 调用 foo()——而不是仅仅调用 foo （）直接地。如果您知道您正在处理哪个类，您可能可以直接调用 foo()，但想法是解耦模块。你的模块不需要知道 Foo 模块的细节——它只需要 notify() 一个监听器（而 Foo 恰好是一个监听器）。通过打破这种依赖关系，单元测试和维护变得更加容易。将来通知 Bar 对象（或任何其他侦听器）也更容易。
谢谢你们。我刚刚开始了解到一切都应该分开，这很有意义。感谢您如此深入的解释。

【解决方案2】：

只需我的两分钱，信号不仅用于（或用于）GUI 工具包。它们用于您希望将数据的生产者与它的接收者解耦的上下文中（例如，上面提到的观察者模式）。如果您将这个想法与线程混合使用，您可以轻松实现 Actor，这是一种有趣的并发任务模式（例如，Erlang 和 Scala 使用 Actor）。

【讨论】：

【解决方案3】：

一种可能的用途是实现 GUI 工具包。您基本上设置了线路以从本机系统获取消息（或它们碰巧被调用的任何内容）以产生信号。从那里开始，用于路由和处理信号的代码可以（至少在某种程度上）是可移植的。

【讨论】：

【解决方案4】：

除了其他人提到的观察者模式之外，任何时候你发现自己必须编写一个回调函数，以便一个类可以通知另一个类发生了某些事情，那么你可以使用 Signals 和 Slots 来代替。与回调相比的最大优势在于它处理了大量的样板代码来添加和删除回调函数，并在调用者或被调用者超出范围时自动断开连接。

回调实际上只是观察者模式的一个实例。

【讨论】：