如果你有很多小班(经常被创建和销毁),并且他们都依赖于设置,你会怎么做?
不必将每一个连接到某种“设置已更改”信号会很好,即使我这样做,所有设置也会更新,即使那些设置没有改变的对象也会更新。
答案 0 :(得分:1)
当我自己面对时,我发现从中央位置控制保存/加载设置会更好。您是否真的需要定期保存/加载设置,或者您是否有实际需要节省的主对象(可能包含子对象列表)控制?或者,最坏的情况是,在创建和销毁对象时,它们会更新父集合中的内存设置映射,并在认为应该保存时保存,而不是子对象销毁。
答案 1 :(得分:0)
下面给出了实现它的一种方法。
如果您愿意,设置的中心位置可以是从QAbstractItemModel
派生的单身,您可以根据需要轻松地将dataChanged(...)
信号连接到各种对象,以接收有关已更改设置的通知。这些对象可以决定是否更改了适用的设置。通过明智地使用帮助程序和填充程序类,您可以非常轻松地将“小类”与通知连接起来。这将解决模型驱动的设置方法中固有的两个问题。
可能会有大量订阅者,他们都会收到有关他们通常不关心的设置的通知(过滤问题)。
将订阅者与项目模型连接起来所需的额外代码,以及关于模型的哪些索引相关的信息重复(选择问题)。
过滤和选择都可以由接收所有dataChanged
通知的填充程序类处理,并且每个有用的索引都维护一个订阅者列表。然后只调用“感兴趣”对象的槽。该类将自己维护用户 - 时隙对列表,而不提供任何其他连接的信号。它使用invokeMethod
或类似的机制来调用插槽。
选择问题可以通过观察订阅者类在初始化时查询模型以查找影响其操作的所有设置的初始值 - 他们“感兴趣”来处理。所有你需要的是您在订户初始化期间创建的临时代理模型。代理模型获取调用者的QObject*
实例,并记录查询的所有模型索引(将它们传递到单例设置模型)。当代理模型最终在订阅者类的初始化返回时被销毁时,它将有关此QObject
的模型索引的信息提供给单例。需要一个额外的呼叫让单身人士知道要调用的插槽,但这就像调用connect()
一样。