将所有内容放在QApplication的子类中是否有意义？

Question

在我的基于插件的架构中，插件必须能够访问应用程序的所有核心组件，例如：主窗口，settingswidget，设置，托盘图标和几个全局不可变变量。

由于应用程序是一个全局单例，因此可以直接将其子类化并使所有这些组件成为应用程序的成员。通过这种方式，我可以轻松地从任何地方访问它们2.我可以为插件设置它们的API 3.组件是“app”的成员感觉很自然。

然而，阅读有关单身人士和全球人的SO课程，感觉就像糟糕的设计，但除此之外，我必须实施核心外观并传递它，感觉设计也不好，并且明确地说不那么直接。< / p>

Answer 1

您的描述看起来像God object。这确实是一个潜在的糟糕设计的标志。

根据您的插件实际执行的操作，Observer pattern之类的内容可能是一种解决方案。不要提供对资源的访问权限，而是让您的对象接受调解器并让它与资源建立连接。

还要看Inversion of control。

Answer 2

我认为在这种情况下，最好区分IS A和HAS A（继承与遏制）。

插件不是QApplication。它使用QApplication。我认为没有任何理由将其作为子类。只需给它指向QApplication的指针或引用。

这是观察者模式为你做的事情之一，主题（QApplication）引用了他们的观察者（插件）。您也可以以对称的方式使用它。

但使用观察者模式并不总是必要的。主要的是你的插件有一个引用或指向QApplication实例的指针。

Answer 3

不确定它是如何起作用的，但似乎单身类有时用于从外部访问它们。 在KDE中，它们似乎被称为Conltroler，并且似乎被用于Plugin-Boundarys。 （KDE是基于QT的，所以我假设KDEPlugin与QT类似。） PS：这是答案形式，因为我没有“到处评论”。