lar*_*moa 24 c++ qt signals-slots qt-signals
我们正在使用提供信号和插槽的Qt,我觉得非常方便.然而,强大的力量带来了巨大的责任,我认为很容易滥用这个功能.
是否有信号槽使用的最佳实践？我很难以这种方式找到一些通用指南.一些问题(我有明确的意见,但并非所有团队成员都同意):
signal displayInfoScreen()必须由显示信息屏幕的插槽处理.关于何时应该/不应该使用信号的任何其他意见都是非常受欢迎的!
Căt*_*tiș 13
信号和插槽功能强大,因为它会分离对象.您不能假设信号已连接插槽,如前所述.
基于信号/插槽的设计的一个主要缺点是,您可以非常轻松地跟踪您实现的逻辑,因为对象的一个动作可以触发连接到发出的信号的任何其他对象的其他动作.更容易产生不必要的副作用,递归调用等.
e8j*_*han 13
使用信号报告
错误是否可以？
是的,例如,请参阅QFtp,其中完成信号带有状态.它不包含实际错误,只包含发生错误的信息.
可以假设信号将被处理吗？
不会.发件人永远不会认为您的特定应用程序可以依赖它.例如,需要处理代表File-New的QAction以使应用程序正常工作,但QAction对象可能并不在意.
信号可用于启动行动吗？例如,信号displayInfoScreen()必须由显示信息屏幕的插槽处理.
再次,是的,例如QAction对象.但是,如果您希望能够重用组件,则必须小心确保实际的类不依赖于它.
使用信号报告错误是否可以？
是的,但我通常会依赖这种情况.如果错误可能异步发生,那么表明这种情况的信号肯定是正确的.如果错误仅在客户端代码调用某个特定函数时发生,则错误应该在该函数的响应中,而不是作为信号.但是,两者之间可能存在各种各样的情况,可能会逐案进行.
此外,信号槽机制可以使跨线程通信更容易(这可能被认为是异步情况),我会将它们用于此目的(错误或否).
可以假设信号将被处理吗？
信号(哲学上)被设计用于表明发生了某些事情.正如其他人所指出的那样,假设一个信号与一个插槽匹配,或者甚至只用一个其他插槽,这绝不是一个好主意.
信号可用于启动行动吗？例如,信号displayInfoScreen()必须由显示信息屏幕的插槽处理.
信号可用于启动操作,但可能与您的思维方式不同.信号表明foo已经发生.如果监视您的类的代码决定在foo发生时,应显示一个对话框,然后使用该信号启动该操作.但是,发出信号的类通常不负责确保发生正确的动作,因为它不负责执行该动作.(如果是,那么它应该是同一类的一部分,并且不需要信号.)