GUI编程的Signals + Slots模型是否有其他实用选择？

如今，大多数GUI工具包都使用Signals + Slots模型。没错，是Qt和GTK +率先提出的。

您知道，小部件或图形对象（有时甚至是未显示的小部件）将信号发送到主循环处理程序。然后，主循环处理程序调用为该小部件/图形对象分配的事件，回调或插槽。virtual工具包通常已经提供了默认的（大多数情况下）事件处理程序来处理所有预定义的信号，因此，与以前的设计不同，开发人员必须自己为每个消息编写整个主循环和处理程序。 （例如WINAPI），开发人员只需要担心实现新功能所需的信号。

据我所知，现在大多数现代工具箱都使用了这种设计。有Qt，GTK +，FLTK等。还有Java Swing。C＃甚至具有它的语言功能（事件和委托），并且Windows Forms已在此设计上开发。实际上，在过去的十年中，这种用于GUI编程的设计已经成为一种不成文的标准。由于它提高了生产率并提供了更好的抽象。

但是，我的问题是：

对于现代GUI编程，是否有并行或实用的替代设计？

即信号+插槽设计是镇上唯一实用的设计吗？用任何其他设计进行GUI编程是否可行？是否有任何其他现代（最好是成功且流行的）GUI工具箱都基于替代设计？

虽然我不会把它所有的是流行的，总会有反应式编程的图形用户界面，尤其是功能性反应式编程，为实现，例如，在.NET框架的Rx在某种程度上更深奥的语言/平台，以及由几个工具包，分别是Haskell和Racket的类似react -banana或FrTime。

这是我最喜欢的主题，并且大约十年（从70年代到86年代），我认为拥有由响应事件的对象组成的GUI才是正确的方法。

然后，我无意中发现了另一种方式来做到这一点说明在这里和一个SourceForge项目在这里。

简而言之，对象的问题在于它们会持久存在，并且如果您编写代码来创建它们，则还必须编写代码以在需要更改的情况下对它们进行增量修改，并以某种方式将消息往返于它们。如果您可以只绘画所需的内容，然后再绘画，如果您想要不同的内容，而不必担心先前对象的持​​久性，那不是很好吗？如果您不必为消息处理而编写代码，因为这一切都是在后台进行的，那也不会很好吗？

那就是那个包裹所做的。对于简单的对话框，它在代码中节省了一个数量级。对于复杂的动态更改对话框，这使它们成为可能。

PS我只对桌面用户界面和远程终端用户界面（而不是Web浏览器用户界面）执行此操作。我敢肯定这是可能的，但我还没有机会尝试。

好吧，有两种不同的方法可以解决此问题：

1. 让每个小部件都公开一种精细的订阅机制（信号/插槽，观察者/可观察的事件，事件/委托），并使客户端代码订阅并采取相应的措施。
2. 针对它所呈现的数据的抽象构建了一个小部件，并让客户端代码实现了该抽象。

这是第二种方法的示例：

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

现在，您可以LabelButton针对进行构建，LabledAction并且客户端代码可以直接实现它，也可以使用一些通用的默认实现（如果适用）。

在某种程度上，第二种方法不那么灵活，但更严格。您不仅可以通过相对原子的方式以某种方式将视图与模型连接在一起。您可以根据需求设计合适的GUI，然后在该GUI与域/应用程序逻辑之间实现适配器。

一些控件类型的系统使用数据库方法-每个gui控件都链接到数据库中的一个文件，以便Gui始终反映数据库状态。DB挂钩用于在值更改时触发功能。